Lilith section updated

I have added the repository by Jos Dreesen on Lilith and the Emulith emulator with a local copy.
Jos maintains a ftp with just the files, I made it available as web pages here with higher availability and easier viewing of images and videos.


School of Niklaus Wirth: The Art of Simplicity

School of Wirth

Got myself an excellent book on the Art of Simplicity. Niklaus Wirth designed programming langauages like Pascal and sequels like Modula-2 and Oberon.  His style and dedication to simplicity in a clear writing and presentation style made a great impression on me.

This book gives unique insights in what has happened and is still happening in the school of Niklaus Wirth. Excellent book!

From the Back Cover

Niklaus Wirth is one of the great pioneers of computer technology and winner of the ACM’s A.M. Turing Award, the most prestigious award in computer science. He has made substantial contributions to the development of programming languages, compiler construction, programming methodology, and hardware design. While working at ERH Zurich, he developed the languages Pascal and Modula-2. He also designed an early high performance workstation, the Personal Computer Lilith, and most recently the language and operating system Oberon.
While Wirth has often been praised for his excellent work as a language designer and engineer, he is also an outstanding educator – something for which he is not as well known. This book brings together prominent computer scientists to describe Wirth’s contributions to education. With the exception of some of his colleagues such as Professors Dijkstra, Hoare, and Rechenberg, all of the contributors to this book are students of Wirth. The essays provide a wide range of contemporary views on modern programming practice and also illuminate the one persistent and pervasive quality found in all his work: his unequivocal demand for simple solutions. The authors and editors hope to pass on their enthusiasm for simple engineering solutions along with their feeling for a man to whom they are all so indebted.


Editors: László Böszörményi, Jürg Gutknecht, Gustav Pomberger

Photos and videos Lilith

In may 2006 Jos Dreesen send me the following photos of a surviving, but then not functional Lilith. In january 2008 Jos succeeded in having this machine running again, one of the few functional remaining Lilith computers (there may be a functioning one at ETH, about ten are known to exist)!





Photos made by Jos Dreesen, 2006

















Photos made by Jos Dreesen, 2008-2012

Niklaus Wirth

niklaus_wirthProfessor Niklaus Wirth is an honered and well respected computer scientist. Very influencal with his work on programming, programming languages and operating systems design. Designer of

Pascal, Modula, Oberon, the Lilith computer and more. As a professor at the ETH in Zurich Switzerland he advanced our knowledge and capabilities with computers and their programming.

On these pages information on:
– work before Pascal: Euler, PL360, Algol W
sources of the early Pascal compilers from ETH Zurich: From 1972 CDC6000 to the Pascal-Px, Pascal-S and the toy/learning compilers Pl/O and Oberon-0
Lilith and Modula
– Oberon to Project Oberon
articles by Niklaus Wirth and others on Pascal, Modula-2 to Oberon
full books by Niklaus Wirth

Wirth not only designed languages, he also supervised and designed hardware and operating systems and applications, combining the strengths of his programming languages with a well suited platform. The first computer is called Lilith, of which about 100 were built around 1980. In 1981 he wrote an article about Lilith: “The Personal Computer Lilith”, on this page you find also photo’s recently made of a surviving and working Lilith computer. Project Oberon followed and, though long retired, he is still working on it!

More videos with Niklaus Wirth on youtube


Summary of projects by N. Wirth, 1962 – 1999

Euler, 1962-1965
Efforts to identify and combine the essential and fundamental concepts of programming languages, in particular of ALGOL 60, led to Wirth’s dissertation under the guidance of Prof. H. D. Huskey at the University of California at Berkeley, and to the definition of the language Euler. The language was implemented on the IBM 704 computer. After publication the project was continued at Stanford University and resulted in an improved implementation on the Burroughs B5000 computer. This work led the foundation for the method of the microprogrammed, stack-oriented interpreter, first tested on an IBM 360/30 computer. This method became widespread much later and was to play a key role in the implementation of high-level languages on microcomputers. Another important aspect of this research was the development of efficient, general parsing methods, and the systematic coupling of semantic interpretation with syntactic analysis. The so-called precedence grammars originated in the context of this project.

ALGOL W, 1964-1967
The work on Euler attracted the interest of the IFIP Working Group 2.1. This group had the task of promulgating and further enhancing ALGOL 60. Three proposals for a successor language were submitted in 1965. In the decisive meeting at Warsaw in the fall of 1966, the proposal of A. van Wijngaarden was elected to be further pursued. In 1970, it eventually became ratified by IFIP as ALGOL 68. Whereas it represented a radically new language, Wirth’s proposal had been less ambitious and based on the idea to extend ALGOL 60. A compiler was implemented for his (subsequently modified) proposal, and it later became used (under the name Algol W) at many universities operating IBM 360 computers. It contributed significantly to uphold the ideas of ALGOL 60.
Since Algol-W was implemented on one of the first IBM 360 computers, and because only an assembler and a Fortran compiler were available, which both were deemed as unsuitable, Wirth conveived a so-called system implementation language. It was supposed to facilitate and speed up the Algol effort, and at the same time it was to be simple enough to avoid a large effort for its own implementation. These goals were fully achieved, and the resulting language PL360 unexpectedly became used at many other installations too. It was the prototype for other, similar developments for other computer architectures.

<strongPascal, 1968-1972
Freed from the constraining influence of a working group’s consensus, Wirth developed the language Pascal in Zurich. The basis was Algol-W and the desire to have a language that would satisfy the requirements of system design (compilers, operating systems, etc.). Also, there was to be a basis of clear concepts and structures, definable axiomatically and independently of any particular computer, as the language was to be suitable also for teaching in an academic environment. Pascal has satisfied these requirements; it is today one of the most widely used languages in computer science education. The first Pascal compiler was designed in Zurich for the CDC 6000 computer family, and it became operational in 1970. Already in 1972 Pascal was used in introductory programming courses.

Venus, 1970-71
In 1970, the Federal Institute of Technology (ETH) acquired a large-scale computer system. In its selection, priority was given to the efficient processing of numerical problems (number crunching). Whereas the concept of time-sharing spread everywhere else, the chosen CDC Cyber system’s software was ill-suited for this mode of operation. Under the direction of Wirth and with the cooperation of the ETH Computation Center, the time sharing system Venus emerged in 1970. It met the stringent requirement of not infringing on the effectiveness of the batch processed number crunching tasks. Wirth programmed the Venus text editor; the system, although by now obsolescent, is still in daily use at ETH. It made it possible to introduce the concept of time-sharing to ETH, without which a modern computation center would be unthinkable.

Pascal-P, 1972-74
It had always been a major goal in the development of Pascal to demonstrate that structured languages need not be inferior to the predominant Fortran, if sufficient attention and care was paid to their implementation. But it soon became clear that industry had no interest in undertaking this demonstrations, although such engineering projects typically should fall into industry’s domain. A second Pascal compiler effort was therefore launched at ETH. The new compiler produced code that was as good as that generated by commercially developed Fortran compilers. Furthermore, this project served as a test for the method of stepwise program refinement propagated by Wirth. A fringe benefit was the welcome capability to satisfy requests to help implement Pascal on other computers, as these requests from other universities became more frequent. The solution lay in replacing the new compiler’s code generator by one producing code for a hypothetical architecture that was easily implemented on other machines in the form of a hand-coded interpreter. This architecture, stack-based, became known as the P-machine, its instruction set as P-code. (P for portable). It became the basis of the large majority of Pascal implementations which first appeared on large-scale computers (IBM, Univac, DEC, Siemens). But the genuine break-through occurred after microprocessors became widely available and it became clear that Pascal-P implementation was feasible for them (UCSD- Pascal).

Modula, 1973-76
Programming languages are mathematical theorems. They represent a methodology of programming, of abstract machine construction. In 1973, Wirth started a project to investigate the basic concepts of designing systems with concurrent processes, i.e. of multi- programming. The emerging design rules (guidelines) inevitably led to the formulation of language constructs expressing the generation and synchronization of concurrent activities. Their embedding in an environment of a minimal support language led to Modula. Implementation was conducted on a PDP-11 computer. A first successful application was the system Hexapus that allowed to connect minicomputers in laboratories with the Computation Center and is still in popular use today.

Lilith, 1977-1981
During a sabbatical year spent at the Xerox Palo Alto Research Center, Wirth was confronted with an entirely new concept in computer usage: the personal work station. Without the least doubt, the personal work station was superior to the conventional computation center almost wherever computers were used: for the computer scientist, the system designer, in the office, the laboratory, and in particular also in the class room. Unquestionably, the advances in microelectronics would make it possible to manufacture personal work stations economically within the next five years. Whoever had a work station at his disposal would be ahead in the development of software suitable to this new mode of operation. In 1977, Wirth initiated a research project to develop a powerful work station: Lilith. A primary objective was to combine the design of hardware and software. Thereby the project expanded into an integrated design effort for hardware, microcode, operating system, compiler, and elementary application programs. The new mode of highly interactive usage required new concepts concerning the operating system and editors.
Inspite of the enormous task, the goal was successfully reached within three years thanks to the intensive and dedicated work of up to seven assistants. Today, 60 Lilith computers are in daily use at the Institute at ETH, and about 250 more in universities and in industry (e.g. Burroughs, Floating-Point Systems, TRW, Tektronix, Signetics) in the USA. Lilith demonstrated that a workstation can be a powerful, convenient, and even economical tool not only in the office, but in applications which so far had been the exclusive domain of large scale computers, such as computer-aided design.

Apart from the operating system and the compiler, interactive editors belong to the basic software of a system intended for program development. Editors were to be designed in entirely new ways; after all, the challenge lay in making optimal use of the new facilities offered by the hardware, the high-resolution, bit-mapped screen, and the mouse as a position input device. Both the prototype text editor Dina and the editor Sil for line drawings were programmed by Wirth himself. Dina was the ancestor of the later document preparation systems Andra and Lara which allow arbitrary text layout and the use of many fonts, and Sil is heavily used to draw all kinds of diagrams, in particular circuit diagrams.

Perhaps the most significant contribution of the Lilith project was that it made it possible to conceive solutions that would not have been thinkable with commercially available products. The first 10 Liliths were installed in 1980, five years before similar systems were marketed.

Modula-2, 1977-1980
Among other things, it was the conscious restriction to use a single programming language only that made the completion of the Lilith project possible in such a short time. Wirth decided to design a revision of Pascal, sacrificing upward compatibility in return for the advantage of avoiding Pascal’s deficiencies: Modula-2. The principal new concepts were:
– The module as a unit of program which can be compiled separately.
– The coroutine as the basic buiding block for systems involving concurrent processes.
– An encapsulated set of types and procedures which allow access to machine-specific objects.

The first Modula-2 compiler was completed at ETH in 1979. It was implemented on a PDP-11 computer and then ported onto Lilith. The interest in Modula-2 soon grew, because it offered considerable advantages over Pascal, particularly in the construction of large systems developed by teams. The compiler was distributed to several hundred universities and places in industry, and soon there were companies offering their own developments (Logitech, Volition Systems, Tartan Laboratories). The advantages of Modula-2 were above all paying off in the development of the Lilith software itself. The compiler, the entire operating system, the editors, and all utilities were programmed exclusively in Modula-2. This demonstrated that the confinement to a single language is not only possible but even advantageous.

Computer-Network, 1980-82
The personal workstation gains enormously in value, if it is connected with other stations via a network. Impersonal stations, so-called servers, are of great importance, such as printers and central file stores. Under the direction of Wirth, a network interface was developed for Lilith, based on the principle of Ethernet. This 3 Mbit/s computer network was the first of its kind in Switzerland.

Laser Printer, 1982
Although Wirth had experienced the impressive versatility and the undisputable advantages of laser printers at Xerox in 1976, he had to wait until 1982 to obtain such a device at an affordable price. He acquired the first laser printer of this kind in Europe (Canon LBP-10), designed the hardware and software interface for Lilith, and thereby showed that Lilith was an ideal real-time computer to drive a laser printer’s video signal, powerful enough to generate the 6 million raster dots of a printed page while the page is moving past the printer’s drum. Under pressure to publish a book on Modula-2, he also programmed the document formatter system Skylla/Zeus, with which it was possible to produce the camera-ready original of the book.

Modula-2 Compiler, 1983-85
Over the years it became evident that the available Modula-2 compilers, including the one from ETH, were less than optimal, and through mediocre performance sometimes deterred users to take full advantage of Modula-2. Wirth decided to develop a new compiler from scratch by himself. It is based on the simple principle of one-pass compilation, whose application had become possible because of the large memories of modern computers, and which eliminates most of the slow accesses to secondary storage devices. The new compiler is remarkable because of its clear structure, its compactness and its efficiency. The program is about 5000 lines long, compared to 10’000 of its predecessor and 100’000 of comparable Ada compilers, and it compiles itself in less than 2 minutes, compared with half an hour required by its predecessor. These advantages are not only visible in the compiler’s use, but they demonstrate that powerful modern languages do not necessarily require giant, complex translators, as is so often claimed.

Ceres 1 – 3, 1984-1990
Five years after Lilith, a second project was started to develop a new workstation. Not the design of a new processor architecture stood in the foreground, but rather the acquisition of know-how in the structure and use of modern hardware technology, also in conjunction with software development. Hence, the computer was to be based on a commercially available microprocessor. The choice fell to the NS32000 family of National Semiconductor (then still called the 16000). After the completion of a prototype with the 32016 processor, both Wirth and co-designer H. Eberle felt that a new design should be based on a 32-bit scheme. The second prototype was therefore built around the NS32032 part, the first genuine 32-bit processor on the market. The memory consisted of 64 256K-DRAM and 32 novel, dual-port 64K-VRAM chips, the latter implementing the frame buffer for the 1024×800 bit-mapped display with minimal bus interference.
In early 1986 33 Ceres-1 computers were built by Hardmeier & Co. in Winterthur, and subsequently tested in our Institute, proving that our goals for robustness and cost effectiveness were well reached. They were immediately put into daily use for research and teaching. A second series was built in the following year.

Progress in semiconductor technology had accelerated to a degree that after only a few years much more powerful machines could be built, even with reduced cost. In 1987-88, Ceres-2 was developed, mostly by B. Heeb under Wirth’s supervision. It was based on the NS32532 processor, delivering a sevenfold increase in power over Ceres-1. The use of 1M-bit DRAMs facilitated the enlargement of memory to 4 or 8 Mbytes. 20 Ceres-2 machines were built by the same company in 1988.

The third model, Ceres-3, was designed in 1989 with the purpose of providing a low-cost workstation for student laboratories. The ratio of power vs. cost was of foremost concern. The station, built around the NS32GX32 processor, also had to operate without any moving parts in order to minimize maintenance cost and noise. No fan was to be used for cooling. The goals were met, and in 1990 100 Ceres-3 were built, all of them by a single engineer in four months. Since then, the machines are in use in offices and mostly student laboratories, connected by a network and served by a Ceres-1 server machine.

Oberon Language and System, 1986-1990
A sabbatical year at the Xerox Palo Alto Research Center (1984-85) brought Wirth into closer touch with the Cedar Operating System, developed in the preceding years at PARC. This was perhaps the first system truly tuned to the needs of personal workstations, and freed from the framework inherited from central computers with a batch processing mode. In daily use, however, Cedar showed all too clearly the symptoms of large software developed by large groups of people: it was bulky and unreliable. It had already become so complex, and its structure had become so intertwined that it was most difficult, if not impossible, to understand it. Wirth decided to undertake the development of a new system, based on concepts suggested by Cedar, but with the firm goal to keep its size such that it could be well understood as a whole, and could be explained in detail in the literature and in courses. Together with J. Gutknecht he worked on the conception and the detailed programming for the following 3-4 years, after which the basic, but easily extensible system was operational.
Although it was planned to use Modula-2 to implement the Oberon System, it soon became evident that a fundamental facility needed for extensibility was lacking: type extension. It was decided to also discard various facilities of lesser importance of Modula-2, and to construct a new, derived language and its compiler. Being an integral part of the project, the language also obtained the name Oberon.

Language and System soon became the standard tools in the Institute for software development, and in particular the development of system extensions. Wirth himself developed and programmed a graphics editor and software for the network connecting the Ceres workstations. A particular challenge was the design of a server station for printing, file distribution, and electronic mail, all together under the constraint of Oberon’s single process property. Using a simple, clear concept proved to be a large benefit; the server operates without failure continuously for years.

Hardware Design with Field Programmable Gate Arrays (FPGAs), 1990-1999
Similarity and difference between hardware and software design always had intrigued Wirth as a topic. With the emergence of programmable logic devices, the gap between the two fields narrowed. A project to familiarize a team with the new possibilities was established, and research in design methods using the new devices was started. It led to a set of design tools, including a specification language (Debora, B. Heeb), its compiler with several “back ends” for printed circuits boards, PLDs, and FPGAs. The usefulness of these tools was demonstrated by applying them in the construction of a workstation (Chamaeleon, also Ceres-3). The construction process starting from a textual specification and ending with a board layout and PLD programs was automated, and it required almost no manual intervention.
Wirth realized early, that FPGAs would be particularly useful as a field for experimentation in learning digital circuit design, replacing expensive, pluggable circuit modules by programmable cells. He equipped 25 Ceres-3 workstations in a student laboratory with an FPGA and uses them intensively in a digital design class. Along with a new project in tool design went the formulation of his language Lola, specifically tailored to the need of teaching in a systematic manner, dispensing with the myriads of side-issues inherent in commercial HDLs. The tool set consists of a compiler converting the program (circuit) text into an abstract data structure suitable for further processing, an editor for constructing circuits implemented by the FPGA, i.e. for generating a layout, and a checker comparing the specification in Lola with the layout.

Automatic Control of Model Helicopter
In 1995 Wirth joined a project undertaken at the Institute of Automatic Control and Measurement. The goal was the development of a system to allow a model helicopter to fly autonomously a preprogrammed path. Wirth designed an on-board computer system with a Strong-ARM processor at its core. Aside from the hardware, he also programmed various software tools, including an Oberon subset compiler with additional features for real-time programming. The computer board was built by I. Noack.
The resulting computer system, called Olga, made use of experience with programmable gate arrays, and used the novel Xilinx-Algotronix 6200 fine-grained FPGA for the generation and sensing of pulse-width modulated signals to control the servos. Furthermore, the computer was connected to a compass, a global positioning system (GPS), and a data link via several standard RS-232 interfaces. This system resulted in a drastic reduction of weight and power consumption, and an increase in computing performance compared to the one used before, in spite of the fact that floating-point arithmetic was to be programmed based on integer arithmetic.

The helicopter carrying Olga weighs about 15 kg and is powered by a 35ccm engine. Wirth pushed for a second project based on a downsized helicopter model with a weight of less than 5 kg and a conventional 10ccm engine. This was realized with a considerably smaller computer board, but the same Strong-ARM core and software base. The large FPGA was replaced by several small PLDs. This project, Horla, was confined to the more modest goal of using the computer only to stabilize the inherently unstable craft, while position, speed and direction would remain under remote control by the pilot.

Both projects collected in a remarkable way the various techniques and tools on which Wirth had worked during the past decade: Compiler, operating system, programmable devices (FPGA, PLD) and their design tools including the language Lola, and circuit design in general. Both projects were successful, although only after several years of effort – and patience.

Wirth became professor at ETH in 1968. In 1970, he and his colleague C.A. Zehnder presented a proposal for the introduction of a curriculum in computer science. A second attempt to establish the subject as an academic discipline failed again in 1974. A new Department was finally established in 1981, and Wirth became its head from 1982 to 1984, and again 1988-1990.
Meanwhile, the computer science courses continued to be directed primarily towards the students of mathematics and electrical engineering. Wirth had a strong influence on the contents of the introductory courses and gave form to many of the advanced courses. Several times his lecture material condensed into books which became translated into many languages: Systematic Programming (1972), Algorithms and Data Structures (1975), Compiler Construction (1976). Also his books Pascal – User Manual and Report (1974), Programming in Modula-2 (1982), Programming in Oberon (1992), and Project Oberon (1993) are widely read.

History of Modula and Lilith

A Brief History of Modula and Lilith

N. Wirth

In the years 1978-1980 the workstation Lilith was developed at ETH Zurich. It featured a microprogrammed processor, a high-resolution display, and a mouse. The entire software was programmed in Modula-2, a language derived from Pascal within the Lilith project. It featured the module with explicit interface specifications, and its implementation included the facility of separate compilation of modules with complete type checking.


In order that a sizeable, technical project be undertaken, two prerequisites must be established. There must be a manifest need for a solution of a relevant problem, and there must exist an idea leading towards a solution of the problem. Such conditions emerged during a sabbatical leave which the author had the good fortune to spend at the Xerox Palo Alto Research Center (PARC) in 1977. The problem I am referring to was the need for a structured programming language for building large, complex systems, and the solution, or rather the feature needed, was a construct for expressing units of separately compiled system components, now known as modules.

I had become confronted with the language Mesa [1], developed at PARC, which contained such a construct. However, I felt that the rather baroque descendant of Pascal could be molded better in accordance with the spirit of Pascal by a new attempt, by defining a more frugal language [2, 3]. Its name Modula witnesses the dominance of the module concept in our concerns, a name which – perhaps unfortunately – was chosen in preference over Pascal++.

The need for a structured language with a module facility was less pronounced in the software community at large than in our immediate environment. An explanation of this requires some digression. The computing facilities available in 1977 were essentially large scale mainframes hosting sophisticated time-sharing systems, accessible only via terminals and remote satellites. The revolutionary concept of the powerful, personal workstation – the Alto computer developed at PARC – appeared to me like a revelation [4]. I was immediately convinced that there was no point in continuing development of software, except if based on and oriented towards this novel computing environment. However, such devices not being available on the market, there remained only one path to proceed, namely to design and build one on our own. Again, there was a recogized need and an idea of a solution. The project produced the workstation Lilith [5, 6].

There is no point in creating new hardware without new software. A basic operating system, utility programs, and first applications were to be developed concurrently, and therefore a programming language and its compiler were required as well. In fact, the primary incentive for designing Modula-2 was the need for a simple, allround language capable of expressing the whole range of programs needed to render Lilith into a powerful software development tool. The explicit goal was to use one and the same language for all Lilith software. Evidently, Modula and Lilith grew as a couple, and it would be futile to record the history of one without that of the other.

Although a preliminary document stating certain goals and concepts of the new language was written in 1977, the effective language design took place in 1978-79. Concurrently, a compiler implementation project was launched. The available machinery was a single DEC PDP-11 with a 64K byte store. The single-pass strategy of our Pascal compilers could not be adopted; a multipass approach was unavoidable in view of the small memory. It had actually been the Mesa implementation at PARC which had proved possible what I had believed to be impracticable, namely to build a complete compiler operating on a small computer. The first Modula compiler, written by K. van Le (1977), consisted of 7 passes, each generating sequential output (intermediate code) written onto the (2 MB) disk. This number was reduced in a second design by U. Ammann to 5 passes (1979). The first pass, the scanner, generated a token string and a hash table of identifiers. The second pass (parser) performed syntax analysis, and the third the task of type checking. Passes 4 and 5 were devoted to code generation. This compiler was operational in early 1979.

By this time the first prototype of Lilith, designed by R. Ohran and the author, was barely operational too. The primary design goal had been an architecture optimally tailored for interpreting M-code, the Modula compiler’s equivalent of Pascal’s P-code. It must be recalled that the era of unlimited memory lay still 10 years in the future. Hence, high code density was considered to be of paramount importance for complex system implementation on small workstations. Lilith was organized as a word-addressed 16-bit computer, M-code as a byte stream. Memory size was 2^16 words (128K bytes). The prototype was built with 4K x 1bit parts.

The best choice for obtaining high code density was to define a fairly large variety of instructions, some of them rather complex, and to build the hardware as a micro-code interpreter. Each M-code instruction consisted of one or several bytes. The first byte was the operation code according to which a sequence of microcode instructions was selected for interpretation. The advantages of this scheme were manifold:

1. The actual hardware could be reasonably simple and therefore fast. The clock frequency being about 7 MHz, a cycle time of 140ns resulted. ALU-functions were addition and logical operations.

2. Simple M-code instructions were implementable with very short sequences of two or three micro-instructions only, requiring an execution time of 280 or 420 ns.

3. More complex instructions, such as multiplication and division, could be implemented by longer sequences of micro-instructions without requiring additional hardware (19 instr. for multiplication, 36 for division).

4. The same operation could be represented with different address or value parameter lengths of 1, 2, or 4 bytes, again without complicating hardware.

Two factors contributed primarily to the achieved high code density, which turned out to be superior to commercial processors by the remarkable factor of 2.5 (M68000) to 3.5 (I8086).

1. The use of several address and operand lengths of 4, 8, 16, and 32 bits. It turned out that more than 70% of all instruction parameters had values between 0 and 15, in which case the operand was packed together with the operation code in a single byte.

2. Lilith was equipped with a stack for intermediate results occuring in the evaluation of expressions. This stack was implemented as a 16-word, fast SRAM. M-code therefore contained no register numbers, as they were implied by the stack scheme.

The most visible innovation brought about by the personal workstation was the high-resolution, bit-mapped display, dramatically contrasting with the then customary displays with 24 lines of 80 characters. Together with the Mouse, it opened a new era of interactive man-machine interfaces based on windows and cursors, scroll bars and title bars, pop-menus and icons. The bit-mapped display with its data stored in main memory required special facilities to generate the video signal with sufficiently high bandwidth. Lilith featured a display of 768 x 592 pixels, which was improved in later versions to the vertical format with 704 x 928 pixels; 50 interlaced half frames required a bandwidth of almost 30 MHz.

The micro-code scheme proved to be most convenient for implementing a small set of raster operations for drawing lines, drawing characters, copying and replicating pixel-blocks. These operations were directly represented as single M-code instructions. The corresponding micro-code routines performed raster operations with spectacular efficiency. As far as the hardware was concerned, the only raster-op specific facility was a barrel shifter allowing an arbitray shift amount in a single micro-cycle. No commercial microprocessor offered a comparable facility.

In the meantime, a new Modula compiler was designed by L. Geissmann and Ch. Jacobi with the PDP-11 compiler as a guide, but taking advantage of the features of Lilith. It consisted of four passes, code generation being simplified by the new architecture. Development took place on the PDP-11, followed by transporting it to Lilith. In the same manner, parts of the operating system Medos was implemented by S. Knudsen – a system essentially following in the footsteps of batch systems with program load and execute commands entered from the keyboard. Concurrently, display and window software was designed by Ch. Jacobi. It served as the basis of the first application programs, such as a text editor – mostly used for program editing – featuring the well-known techniques of a cursor/mouse interface and pop-up menus.

Modula-2 was now in daily use and quickly proved its worth as a powerful, efficiently implemented language. In December 1980, the first pilot series of 20 Liliths, manufactured in Utah under the supervision of R. Ohran, were delivered to ETH Zurich. Further software development proceeded with a more than a 20-fold hardware power at our disposal. A genuine personal workstation environment had successfully been established.

From the preceding account it should become clear under which conditions Modula came into existence. It is evident that our primary concern was not a language satisfying all wishes of all programmers, but the creation of a sufficiently powerful tool for implementing an entire software system in a short time with the limited manpower at hand. Modula-2 was, so to speak, a subordinate goal, a means to an end.

Modules and separate compilation
The decision to move from Pascal to a successor was primarily due to the high importance attributed to a clean formulation of the module concept and its implementation as a facility for separate compilation. Therefore, the solution adopted in several commercial extensions of Pascal, namely the merging of units in source form, was rejected. The notion of modules with explicit lists of imported and exported identifiers was adopted from Mesa. Also the symbol file as precompiled information about a module’s exported objects, stemmed from Mesa. The module concept gave rise to a new view of Lilith’s operating system: the traditional division into system and application programs was replaced by a single hierarchy of modules which could be expanded or shrunk as momentary needs dictated.

Modula’s idea of a module was that of a syntactic unit encapsulated by a wall through which identifiers are invisible except if listed in the export or import list. Since syntactic constructs are usually defined recursively, modules are nestable with obvious consequences for identifier visibility. The inner, or local module turned out to be of limited usefulness in practice and was rarely used. Considering that implementations must handle global and local modules differently – the global ones are separately compilable – local modules should probably not have been introduced in the first place. Import lists could assume one of two forms. The simpler form consists of a list of module identifiers:


An object x exported from module M1, for example, is then referenced in a client of M1 by the qualified identifier M1.x. The second form of import list seeks to abbreviate program texts, letting the qualification be omitted by specifying the source of an identifier directly:

FROM M1 IMPORT x, y, z;

Like most abbreviations, its value is rather questionable. Not only does the compiler become more complicated, but certain negative side-effects are unavoidable: identifier clashes. If two modules export an object with the same name, a clash occurs if they are imported in the second form, even if the identifier in question was not used.
On the other hand, critics of Modula expressed the opinion that our concept was too simple and restrictive. Their view of the module interface – i.e. of Modula’s definition part – was that of a selection of the module’s set of objects. Modula allowed to define a single selection only, whereas a multitude of different selections for different clients might be useful. This facility was implemented for the language Cedar [7]. It gives rise to further extensions and complications. An obvious desire is to derive unions and intersections of selections.

A further point perhaps worth mentioning in this connection is the handling of exported enumeration types. The desire to avoid long export lists led to the (exceptional) rule that the export of an enumeration type identifier implies the export of all constant identifiers of that type. As nice as this may sound for the abbreviation enthusiast, it also has negative consequences, again in the form of identifier clashes. This occurs if two enumeration types are imported which happen to have at least one common constant identifier.

Furthermore, identifiers may now appear that are neither locally declared, nor qualified by a module name, nor visible in an import list; an entirely unexpected situation in a structured language.

Static type checking
Modula-2’s design followed uncompromisingly the rule – the dogma even – of strictly static typing, thereby empowering a compiler to perform all type consistency checks and avoiding any of them to be delayed until run-time.

In this respect, Pascal contained a few mistakes that had to be mended. One of them was the incompleteness of parameter specifications adopted from Algol 60 as exemplified by the following declarations:


VAR a, b: REAL;
BEGIN … p(a + b) … END ;
… Q(P) …

Here, the call P(a+b) does not comply with the parameter specifications of P, but this fact cannot be discovered by a static text analysis. Modula mended this deficiency by requiring complete parameter specifications:


Pascal permitted the use of integer as well as real operands in expressions (mixed expressions), postulating automatic conversion of number representation wherever necessary. The presence of a large number of basic types complicates the generation of code considerably, and hence it was decided that no automatic conversion would be generated. This, in turn, required that the language rules must prohibit mixed expressions. This decision is indeed questionable, but perhaps understandable in view of our own immediate needs, which were very modest in the realm of arithmetic.
How, then, can the introduction of type CARDINAL be explained, of natural numbers as a further basic data type? The need arose from the necessity to represent addresses as a numeric type. Lilith being a 16-bit machine with a store of 2^16 words, a useless sign bit could not be afforded. As unproblematic as this new type at first appeared, it gave rise to several problems. How, for example, is a comparison i < c to be implemented efficiently?

The question is simply avoided, if mixed expressions are prohibited. Two distinct sets of instructions are required for integer (signed) and cardinal (unsigned) arithmetic. Even if the same instruction can be used for addition, there exists a difference in the definition of overflow. The situation is even more problematic for division. In mathematics, the quotient q = x DIV y and the remainder r = x MOD y are defined by the relationships

x = q*y + r, 0 <= r < y

Integer division, in contrast to real division, is asymmetric with respect to 0. For example

10 DIV 3 = 3 10 MOD 3 = 1
-10 DIV 3 = -4 -10 MOD 3 = 2

Most computers, however, offer instructions that are wrong with respect to the established definition. They treat integer division like real division with symmetry respective to 0:

(-x) DIV y = -(x DIV y)
(-x) MOD y = -(x MOD y)

If integer division is implemented correctly, divisions by powers of 2 can be made more efficient by simple shifts. In the case of wrong division instructions, this is not possible:

x * 2^n = left(x, n) x DIV 2^n = right(x, n)

The following processors, among others, perform integer division contrary to its mathematical definition: Motorola M680x0, Intel 80×86, Intel 80960, DEC VAX, IBM Power. Even worse, the language Ada institutionalizes this mistake by declaring it as standard.
We decided to adopt the wrong arithmetic in order to stay consistent with the mistakes others were demanding. In hindsight this was, of course, a grave mistake. The compiler uses shift instructions for multiplying and dividing by powers of 2 in the case of expressions of type CARDINAL only.

In summary, then, the type CARDINAL was justified by practical needs for 16-bit address handling. From the point of view of mathematicians (who have invented negative numbers for the sake of algebraic completeness), however, it must be called a step backwards, as it introduced difficulties for the programmer that did not exist beforehand. Consider, for example, the following statements performing an operation Q for x = N-1, … , 1, 0:

x := N-1;
WHILE x >= 0 DO Q; x := x-1 END

If x is of type INTEGER, the program is correct; but if it is of type CARDINAL, it leads to an underflow which is avoided by the correct, alternative formulation

x := N;
WHILE x > 0 DO x := x-1; Q END

The advent of the 32-bit computer some 6 years later provided the welcome opportunity to forget the type CARDINAL. The episode shows how inadequacies in hardware may force the language implementor to accept complications and compromises, if he wishes to fully exploit the available facilities. The lesson is, that a memory size of 2n requires arithmetic with (at least) n+1 bit integers.

Procedure types

An uncontroversial, fairly straight-forward, and most essential innovation was the procedure type, also adopted from Mesa. In a restricted form it had been present also in Pascal, namely in the form of parametric procedures. Hence, the concept needed only to be generalized, i.e. made applicable to parameters and variables. Although the facility was sparingly used in Lilith software – with the exception of later editors and some instances in the operating system – it is nothing less than the basis for object-oriented programming, with record (object) fields having procedures as “values”. Nevertheless, Modula-2 cannot be claimed to support object-oriented programming.

The single facility missing is one for building new data types based on others, i.e. of types that are (upward) compatible with existing types, or – in object-oriented terminology – that inherit properties from existing types. This essential facility was introduced in Modula’s successor Oberon [8, 9], where it was appropriately called type extension [10].

Although Modula does not support object-oriented programming, it at least makes it possible through the use of the type ADDRESS and the rule that an address value may be assigned to any pointer variable. This implies of course that type checking be overruled, a sacrifice of security that weighs heavily. The “trick” lies in providing every record type that is to be extensible with an additional field of type ADDRESS. Record extensions then require a second block of storage, separately allocated, whose pointer is assigned to that field. Needless to say, the additional indirection in accessing fields of the extension, as well as the cumbersome formulation for breaching the type system, are unsatisfactory. Oberon’s neatly integrated concept of type extensions solves these problems admirably well; its price is a run-time check of type consistency in those cases where it is inherently unavoidable.

Low-level facilities
Facilities that make it possible to express situations which do not properly fit into the set of abstractions constituting the language are called low-level facilities. In a way, their presence is a symptom of the incompleteness of the set of provided abstractions. Given our task of building an entire operating system for Lilith, however, at the time they were unavoidable. I nevertheless believe that they were introduced too light-heartedly, in the naive belief that programmers would use them only as a last resort.

In particular, the concept of type transfer function was a major mistake. It allows the type identifier to be used in expressions as function identifier: The value of T(x) is equal to x, whereby x is interpreted as being of type T. This interpretation inherently depends on the underlying (binary) representation of the type of x and of T. Therefore, every program making use of this facility is inherently implementation-dependent, a clear contradiction of the fundamental goal of high-level languages, i.e. of abstraction. The situation is particularly deplorable, because no hint is given of such dependence in a module’s heading.

Into the same category of easily misused features belongs the variant record. The real stumbling block is the variant without tag field. The tag field’s value is supposed to indicate the structure currently assumed by the record. If a tag is missing, no possibility exists for checking (or determining) the current variant. It is exactly this lack which can be misused to access record fields with “wrong” types:

2: c: BITSET

From the assignment x.a := -16 follow the equalities x.b = 65520 and x.c = {4 .. 15}. Or might the latter be x.c = {0 .. 11} ? Needless to say, such programs are ill-defined, hard to understand, and they defy the concept of abstraction and portability.
After 1982, Modula-2 aroused interest in several industrial organizations. The first commercial compiler was built by Logitech S.A., and others followed [11]. IBM produced a compiler and programmed its AS-400 operating system in Modula, and DEC’s Systems Research Center adopted Modula-2 for its internal projects, at the same time extending the language into Modula-2+ [12]. Its creators found Modula-2 lacking in three areas: Concurrency, storage management, and exception handling.

A project to investigate techniques and problems in multiprogramming had been undertaken at our Institute during the years 1974-76. It led to a small, experimental language implemented on the PDP-11 computer [13]. Its basis for multiprogramming were monitors and conditions (here called signals) as proposed by C.A.R. Hoare [14]. Monitors were generalized into modules; the concept of encapsulation was thereby disconnected from that of mutual exclusion. Interrupt handling was integrated into process scheduling in the sense that process switches could be triggered either by programmed signal operations (send, wait) or by interrupts. These were considered as external signals, thereby conceptually unifying declared signals and interrupts.

The project led to the conclusion that there existed no clearly preferrable set of basic constructs for expressing concurrent processes and their cooperation, but that processes and threads, signals and semaphores, monitors and critical regions all have their advantages and disadvantages, depending on particular applications. Hence, it was decided that only the very basic notion of coroutines would be included in Modula-2, and that higher abstractions should be programmed as modules based on coroutines. This decision was even more plausible, because the demands of the Lilith software as a single-user operating system were easily met without sophisticated facilities for multiprogramming, which therefore did not merit attention with high priority. However, the belief that coroutines would also be a suitable basis for genuine multiprocessor implementations was mistaken, as was pointed out by the Modula-2+ authors.

We have also abandoned the belief that interrupt handling should be treated by the same mechanism as programmed process switching. Interrupts are typically subject to specific real-time conditions. Real-time response is impaired beyond acceptable limits, if interrupts are handled by very general, complicated switching and scheduling routines.

Storage management and garbage collection

Modula-2, like Pascal, features pointers and thereby implies dynamic storage allocation. Allocation of a variable x^ is expressed by the intrinsic procedure NEW(x), typically implemented by a system call.

The premise underlying Modula-2 implementation was that programs would handle pools of dynamically allocated variables, one for each (record) type. Such individually programmed handlers could be tuned optimally to the specific conditions of an application, thus guaranteeing the most effective use of storage. This was of great importance at the time, considering the small storage size of computers and the absence of centralized storage management. Today’s very much larger memories render this strategy obsolete and make a flexible, centralized storage management indispensible.

Were it not for the unfortunate and abundant features for breaching the type system, Modula-2 would still satisfy the needs imposed by centralized management, i.e. allow operation on the basis of global garbage collection. A garbage collector must, however, be able to rely on uncorruptible type information at run-time. Type breaching must be impossible. In a way, Modula-2 was too “powerful”. This reminds us of the old wisdom that the power of a language is not only determined by what it allows to express, but equally much by what it prohibits to express.

Exception handling
By handling an exception we generally understand the transfer of control to an implicitly designated statement sequence upon the rare occurrence of a certain condition. What distinguishes, then, “exception handling” from conventional if-statements, except the rarity of the condition? Three items come to mind:

The statement sequence (exception handler) resides in a module different from where the exception is detected (raised).

Several entered procedures need to be terminated exceptionally (aborted). Separating the program text for handling the rare condition from the program specifying the “regular” behaviour is supposed to improve program clarity. Only the second item calls for a facility that is not expressible by conventional constructs. The question then is: Does such a new facility correspond to an important abstraction that truly clarifies programs, or is it merely a convenient abbreviation for frequently occurring situations? And: Is an implementation possible that does not impair efficiency?

The first question can never be answered conclusively. It dependes not only on personal preferences and programming style, but also on the applications considered. A proposal for inclusion of an exception handling construct was already contained in a first draft of Modula-2, but dropped later, because a need for it was not convincingly established. The development of entire operating systems [15] at least showed that the omission of exception handling was not entirely mistaken. The emergence of systems with languages where exception handling was available and – as a consequence – heavily used and frequently even misused, suggests that the decision was even right.

Nevertheless, I am aware that other people – no less experienced in system construction – do not share this view. One fact, however, is undisputed: a feature can always be added to, but never removed from a language. It is therefore recommended to start out with features of established indispensability only.

Later developments
During 1984, the author designed a new compiler for Modula-2. I felt that many parts of compilation could be handled more simply and more efficiently, if use were made of the now available larger store (which, by today’s measures, was still very small). Lilith’s 64K word memory and its high code density allowed the realization of a single-pass compiler. This implied a dramatic reduction of disk operations, which happen to contribute the largest part to compilation time. Indeed, compilation time of the compiler itself was reduced from some 4 minutes to a scant 45 seconds.

The new compiler retained, however, the partitioning of tasks. Instead of each task constituting a pass – with sequential input from and output to disk – it constituted a module with a mostly procedural interface. Common data structures, such as the symbol table, were defined in a data definition module imported by (almost) all other modules. These modules represented a scanner, a parser, a code generator, and a handler of symbol files.

When a new compiler is developed, the temptation to include some changes in the language is seldom resisted. Also in the present case, some clarifications and changes were postulated and incorporated in a revised language definition. The only significant change, however, concerned definition modules (or rather: the definition part of a module). The change postulated that all identifiers declared in a definition part were exported, and this made export lists superfluous.

On the side of the operating system a significant step forward was the implementation of a network. We adopted the experimental Ethernet technology from PARC, a bus topology with a 3 MHz bandwidth and Manchester encoding, yielding a transmission rate of 3 Mbits/s. Both hardware interfaces and the software were developed by J. Hoppe. The services were dominated by file transfer, and therefore the network was connected with the file system at a low level, such that access to both remote and local files was distinguished by a file-name prefix only.

The presence of a network connecting all workstations called for servers, i.e. for “impersonal workstations”. The first server that went into operation in 1982 was a print server connected to a laser printer (Canon LBP-10). Due to the flexibility and power of Lilith, a regular workstation could be used for generating the bitmap and for driving the printer. The hardware interface consisted merely of a direct memory access channel (DMA), effectively similar to a display driver, but suitably adapted to accept synchronization signals from the printer. Since memory was too small to hold an entire page (about 1 Mbit), bitmap generation and data transfer to the printer video had to proceed concurrently. It fortunately turned out that Lilith was sufficiently powerful to allow bitmap generation on-the-fly. Thereby Lilith became the first computer in Europe to make full use of laser printing capabilities, printing texts with various fonts and styles, and graphics ranging from scanned pictures to circuit schematics.

The second server, operational in 1983, was a file server using, in contrast to regular workstations, not only a 10 MByte cartridge disk, but a high-volume (500 MByte) Winchester drive (Fujitsu Eagle), which constituted leading edge-technology at the time. The large size required a different organization of the file system. Also, the concept of stable storage was implemented. This research was performed by F. Ostler.

A sizable effort extending over the years 1981-1985 went into the development of applications. In the forefront were document editors making use of all the novel facilities put at our disposal by Lilith, from bitmapped display and mouse to network and laser printer. The first attempt by J. Gutknecht and W. Winiger led to the editor Andra [16]. It employed the piece list technique for representing the edited text, pioneered by B. Lampson at PARC, as well as windows and pop-up menus for its user interface. It allowed the use of multiple fonts and various formatting modes, and it considered a document as being hierarchically structured. The follow-up project by J. Gutknecht and H. Schar led to the editor Lara [17] which became the chief application program for Lilith users for many years.

Other significant applications were a set of tools for interactive font design, implemented by E. Kohen, and a line drwing graphics editor, developed by the author. The common characteristic of all these tools was that they went into immediate use by our own team, thus providing feedback not only about their own appropriateness, but also on the adequacy of Modula and the entire system.

Lilith and Modula-2 were the backbone tools for education in programming at the Computer Science Department of ETH. About 60 Liliths were in use by 1982, offering a modern environment for programming and for document preparation about five years before similar tools were available commercially. The Lilith computers were decommissioned in 1990; they had been in daily use for 10 years.


1. Mesa Language Manual. Oct. 1976, Xerox PARC.

2. N. Wirth. Programming in Modula-2. Springer-Verlag, 1982.

3. J. Gutknecht. Tutorial on Modula-2. BYTE, Aug. 1984, 157-176.

4. C. P. Thacker, et al. Alto: A Personal Computer. CSL-79-11. Xerox PARC.

5. N. Wirth. Lilith: A Personal Computer for the Software Engineer. Proc. 5th Int’l Conf. on Software Engineering. San Diego, 1981. IEEE 81CH1627-9.

6. R. Ohran. Lilith and Modula-2. BYTE, Aug. 1984, 181-192.

7. W. Teitelman. A Tour through Cedar. IEEE Software, 1, 2 (April 1984) 44-73.

8. N. Wirth. The Programming Language Oberon. Software – Practice and Experience, 18, 7 (July 1988), 671-690.

9. M. Reiser and N. Wirth. Programming in Oberon. Addison-Wesley, 1992.

10. N. Wirth. Type Extension. ACM TOPLAS, 10, 2 (April 1988), 204-214.

11. P.H. Hartel and D. Starreveld. Modula-2 Implementation Overview. J. of Pascal, Ada, and Modula-2. July/Aug. 1985, 9-23.

12. P. Rovner. Extending Modula-2 to Build Large, Integrated Systems. IEEE Software, Nov. 1986, 46-57.

13. N. Wirth. Modula: A Language for Modular Multiprogramming. Software – Practice and Experience, 7 (1977), 3-35.

14. C.A.R. Hoare. Monitors: An Operating Systems Structuring Concept. Comm. ACM, 17, 10 (Oct. 1974), 549-557.

15. N. Wirth and J. Gutknecht. Project Oberon. Addison-Wesley, 1992.

16. J. Gutknecht, W. Winiger. Andra: The Document Preparation System of the Personal Workstation Lilith. Software- Practice & Experience, 14, (1984), 73-100.

17. J. Gutknecht. Concepts of the Text Editor Lara. Comm. ACM, 28, 9 (Sept. 1985), 942-960.


Emulith is a functional emulation of the ETH Lilith Modula2 Medos  computer. Its is programmed by Jos Dreesen, owner of one of the few remaining operational Lilith’s.

The Lilith emulator Emulith is a functional equivalent of the actual Lilith hardware, uses unchanged microcode and disk images of the real machine and gives a reasonable good idea of what the real Lilith looks like. High resolution display, cartridge disk, mouse and keyboard are all part of the emulation. Not covered (yet ?) are RS232, Ethernet and printer interface.
The following hardware and software is needed to run Emulith :

    • A reasonable fast PC ( > 1 GHz) running Linux. Ubuntu is fine, even the Live cD.
    • Minimal screen resolution of 1280×1024 ( The Lilith itself has a 704×928 resolution).
    • Some willingness to read documentation : the Lilith is a 25 year old system and its
      usage is not comparable with current operating systems.

A Lilith manual is part of the documentation.

The performance of Emulith on a 1 GHz machine is comparable with the real hardware, which used a 7 Mhz main clock. Any operation involving the disk is considerably faster on the emulator.

Download the emulator (check for new versions!) at the Emulith ftp. or from the local copy, see below.  It runs fine on Windows XP to 10 32 and 64 bit, Linux, MacOS.

Here a local copy of the ftp Lilith repository from Jos Dreeesen.

Emulith Manual
emulith_v13 Windows installable/a>

Lilith Handbook Aug 82
Lilith hardware manual description of the Lilith machine
Lilith install
Lilith mcode interpreter
Lilith microcode bitslice microcode listing
Lilith schematics in Eagle format
Lilith schematics and netlists

Wirth on the Personal Computer Lilith, ETH 1981
Radio Computer Bulletin april 1982 Article on Lilith
D100,D120,D140 : Honeywell-Bull Mididisk documentation
D100_Mididisk controller
D120 product manual
D120 product spec
D140 product spec
Western digital MFM controller

DPU monitor
Hardware test2 list
Hardwaretest list

Machinecode listings for a 6802 based Lilith debugging tool, the DPU monitor.

Submon list
Machinecode listings for a 6802 based Lilith debugging tool, the DPU monitor.

eth7346 Medos2 1983
ETH7646 Lilith a Workstation Computer For Modula2 1984

All *list.pdf files are machinecode listings for a 6802 based Lilith debugging tool, the DPU monitor. They are not used in normal operation of the Lilith.

Release notes 19-03-2012

7-12-2008 – first release ( V1.00). 50 downloads and counting…

9-12-2008 – Mac OS-X binary (intel/universal) added. ( courtesy of Ingo Pascke)
– corrected diskimage added. Solves modula-2 compiler problems.
dsk_8_ok.img replaces dsk_8.img.

13-12-2008 – Source code for V1.10 ready :
Added OS-X #ifdefs, should now compile for OS-X without changes.
Removed registerdisplay, added speed display.
Landscape / Portrait mode switch.
Setup Switches block for landscape mode added.
Black on White / White on Black switch added.
Main display border can be suppressed
Parameters stored in .ini file
Manual still to be updated ….
21-02-2009 – Release 1.20
Port to FLTK.
Native windows version
Menu based GUI
updated manual
big/small gui selection
Filetransfer to / from hostsystem
Partial FD6502 support ( use with “applecopy”)
Medos V4 now boots
Help text added.
8-3-2009 – Added Mac OS-X package ( intel only).
– Download
– unzip and mount .dmg file.
– Move the emulith directory to /Applications
– Start emulith.

The location of the binary MUST be /Applications/emulith
Manual is still to be updated.
7-4-2009 – 15 disk images put online ( )
24-5-2010 – Version 1.21
– memfilexfer now works ( copies files across disks )
– minor tweaks to get rid of some compile warnings.
Updated Makefile to define fl_ask_h, so avoiding the associated problems.

To do : – update windows & Mac builds
– get the mouse action to behave itself
– Make an overview of all available disk and the software thereon.
1-03-2012 – Read all 38 HB120 disks of Museum for Kommunikation Berne.
Compilable source code for modula 2 V19, Medos 4 and many applications found.
– Generated some videos of some Emulith sessions.
18-03-2012 – Version 1.30. Basic CPU emulation still unchanged.
– memfilexfer now really really works ( copies files across disks )
– Directory for virtual floppy can be selected. This enables working with more that one virtual floppy.
– Minor fixes here and there.
– Disk image location now flexible.
– Mouse somewhat improved, basic problem ( no events when host mouse outside window) seems unsolvable.
– Video output possible ( with some manual work, and only tried on Ubuntu though…)
– “startup.cmd” will be read on startup to provide initial keyboard input.
– Some videos generated from the emulator output.
– Microcode release 14 made. This will interface the Lilith to an ATA disk at IO group 4.
All existing software should run without change.
This should greatly ease a future FPGA reimplementation.

To do : convert real Lilith to ATA disk, sort MfK disks, prepare and test software packs
19-03-2012 – Fixed keyboard input issue on OS-X.
OS-X performance issues need a long term approach..
Compilable Medos source code in ( but .MOD not usable/readable in modern systems )
Non-Compilable Medos source code in ( but .MOD readable in modern systems )

Books by Niklaus Wirth

Niklaus Wirth is a gifted writer. His easy to read style and the simplicity that must have taken so much effort to achieve makes his books jewels in the often so obscure computer science world.

A list of his publications is at his homepage. The books listed below are the full books in PDF format

Pascal User_Manual and Report Second Edition
Pascal User_Manual and Report Fourth Edition ISO standard
Algorithms+ Data Structures = Programs, 1976
Algorithms+ Data Structures = Programs, 1976,
Chapter 5: PL/0 Compiler
Algorithms+ Data Structures = Programs, 2004, Oberon version
Algorithms+ Data Structures = Programs, 2012, Oberon version
Algorithms+ Data Structures = Programs, 2017, Oberon version
Compiler Bau, 1986, German
Compiler Bouw 1986, Dutch
Compiler construction 1996
Compiler Construction, 2005 (PDF), (TXT)
CompilerConstruction 2014 part 1, part 2
CompilerConstruction 2017 part 1, part 2
Modula-2 Handbook
Programming in Oberon 1992
Programming in Oberon, 2004
Programming in Oberon, 2015
Project Oberon, 2005
Project Oberon, Chapter 1-9, 2013
Project Oberon, Chapter 10-15, 2013
Project Oberon, Chapter 16, 2013
RISC Architecture, 2014
RISC5 Architecture Update, 2018
How to use the Oberon System, 2015
The School of Niklaus Wirth

Besides these books scanned in PDF format, the next books are also on my shelf: