I have always been interested in the idea of a universal computer; a computer which, by virtue of a very simple, modular, and infinitely scalable hardware architecture, becomes as universal a technology as the technology of the paper book yet, by virtue of its infinite flexibility does not become stifled in its evolutionary progress. Having grown up during the early days of the microcomputer revolution, I was always troubled by the obvious dichotomy in the implementation of the technology. Here was a new technology attributed with an almost frighteningly fast pace of evolution yet it was very obviously not an evolution enjoying any real self-optimization. In other words, even at a young age I could recognize that this technology was in danger of going the way of the automobile, its actual progress ultimately doomed to be halted by the increasing drag of ballooning vested interests while the general public is fooled by superficial design into an annual cycle of forced obsolescence and perpetual material waste. And, so far, it appears my concerns were valid. Today we struggle under the yolk of monopolistic system platform developers, competing psuedo-standards spawn like fractals and drive the cost of innovation higher and higher, dubious patents filed by unscrupulous technology speculators have turned the industry into a legal mine-field, and all effective progress with the personal computer has ground to a near complete halt, replaced by a numbers game as subcomponent makers continue to improve the raw performance of their products but the hardware architectures they plug them into remain primitive. Many financial analysts point to the simple lack of anything significantly new or progressive as the root cause of the current computer industry sector slump. The contemporary personal computer has become just like the automobile where every year a slew of new models with utterly superficial design changes are introduced promising all kinds of new features and performance and yet, on average, little functional improvement is ever realized.

Long ago I recognized the root of this problem as resting in the monolithic nature of the microcomputer itself. The ability to package a complete miniaturized version of a computer that once required a whole room to itself onto a single was an incredible breakthrough, made possible by the introduction of the single-chip microprocessor. But this also presented one very critical drawback; it rigidly locked the hardware architecture of the microcomputer into a single form. Almost immediately this proved to be a problem as a result of chronically poor design by personal computer engineers who seemed forever ignorant of the full extent of the subcomponent products actually available to them or the practical needs of programmers and ultimate end-users. Immediately the personal computer marketplace became a battle ground for competing hardware platforms that were quite deliberately engineered for incompatibility as a gimmick by which to control market share and which cultivated likewise antagonistic cultures of users. To this day I marvel at the gullibility of computer enthusiasts who endlessly argue the virtues of one computer platform over another, utterly oblivious to how they have been duped by the computer makers to rationalize utterly superficial yet proprietary differences in architecture as critical to performance when, in truth, it has never been about anything but locking-in market share. Difference only for its own sake and any actual productivity virtues almost accidental.

Of course, not fully understanding then the extent to which the differences in competing personal computer platforms were really about protection of market share -as opposed to engineers' personal tastes and biases- I naively thought that I could resolve this threat to progress through a kind of meta-computer architecture so flexible it could literally swallow-up the proprietary hardware of all competing computers and become a new open standard. Thus in the early 1980s I devised an unusual system concept called The City of Refuge under a scheme called Project Kamehameha. The City of Refuge was a modular microcomputer using a book-case module design similar to that of many passive backplane based industrial computers of the time. However, rather than using an actual passive backplane chassis and enclosure like industrial computers, the CoR used a then unique pass-through backplane akin to what is now employed in the PC-104 industrial computer platform. The hardware was composed of a series of self-contained single-board modules each in its own little flat case similar to that of a modem but with a pair of pass-through bus connectors that allowed the system to be assembled like books in a book-case. The base of the system was a power supply module into which the 'master' CPU unit was plugged and then accompanied by one or more peripheral modules for mass storage, video and sound, and so on. A key innovation was that this planned use of a monochrome electroluminscent display panel, making this one of the first proposed desktop computers to feature a flat panel dispay. But the most critical innovation was the idea of multiple alternative CPU modules which could run concurrently. The purpose of these was not simply to afford the system parallel processing capability. Rather, it allowed the computer to add CPU modules with different microprocessors and internal architectures, allowing the computer to incorporate the proprietary architectures of competing computer platforms, their software running from the same mass storage devices but in isolation from the software of other systems as though each different CPU module were a hardware based emulator. This -in theory- would have forced the different system platforms to compete on a truly even playing field and ultimately merge into one standard architecture as users pressured software developers to facilitate interoperability between them and the native code programs they hosted. To facilitate this the CoR would be based on its own graphical user interface based operating system which would allow the software running on different CPUs to coexist in the isolation of discreet run-time windows.

No surprise, there was no interest in this idea from any existing computer company and, lacking the resources to realize this product myself, I abandoned it. But I have never quite abandoned this idea of an open-architecture public domain 'meta-platform' that could unify the computing industry without limiting the technology's potential for progress. Over time this evolved into a theory of dynamic distributed system architectures which I have come to refer to as the Distributed Computer -not to be confused with the concept of Distributed Computing which is a method of exploiting multiple networked computers to perform parallel processing tasks. This has of late evolved into a concept for a network based computing platform which I have observed is already starting to evolve among the spectrum of Internet based products. This has led me to the conclusion that we may soon see the realization of the Distributed Computer not as the product of a specific computer company -they are currently too self-absorbed and narrow-minded to ever get it- but rather the convergence of a number of market forces which are already compelling the computer-like interoperability of network 'appliances' which will ultimately evolve into the components of this new class of computer.

My first concrete concept of a Distributed Computer developed from my growing personal frustration with the failure of the most popular personal computers to demonstrate any significant improvement in their design, especially in terms of their ergonomics, their implementation of network systems, their integration of media technology, and in light of the sudden emergence of the Internet as a mainstream public network. I was sensing the slow-down in progress in the industry and it troubled me. For decades computer industry pundits had been predicting that the personal computer would physically 'disappear' into the infrastructure of civilization. They described a future of ubiquitous networks where the clunky hardware common today would be hidden away, the desktop boxes and cumbersome laptops replaced by elegant tablet devices and the divergent and isolated assortment of contemporary media finally converging in their digital forms under this new ubiquitous computing environment. But now we had the beginning of this ubiquitous network environment and, aside from Xerox's rather nebulous and drawn-out Ubiquitous Computing research program, the personal computer industry as a whole was going in the completely opposite direction. Utterly lost to the pathological cycle of Detroit-style superficial innovation, computer designers persist in the perpetual repackaging of primitive computers as silly desktop object'd art. And, let's face it, the Internet took virtually everyone in the self-absorbed personal computer industry by surprise. That's how far out of the loop they had, by then, become.

So I asked myself, what exactly would the computer these pundits keep predicting be like? How would one implement the capabilities they have envisioned? Clearly, the conventional microcomputer would have a hard time doing this because of the monolithic nature of its architecture. The revolutionary innovation which once afforded the miniaturization that put powerful computers into everyones hands has now become an albatross around the neck of the industry and so it needs to be rethought. It's no longer enough for the peripherals of a computer to be interchangeable and its core architecture cast in stone. Everything that makes up the computer, all its sub-systems, need to become modular and dynamically reconfigurable. Why? Because the motherboard, and its host of proprietary architectures, has become the critical bottleneck to a system's evolution and flexibility. Realizing the potential of ubiquitous networking calls for a level of interoperability that is impossible unless the differences in underlying system hardware are effectively isolated. In other words, the standards of the network have to function effectively at a very low level to achieve the necessary interoperability future applications demand with a practical economy of software and hardware. Already we see what a ridiculous mess the old fashioned way of doing things in this industry has made of Web browsers. Either the industry outgrows this primitive gimmick of market share cultivation through superficial proprietary technology or you can just bury it. So we need to obsolesce the motherboard and the 'platform moguls' that exploit its monolithic nature and move that standards power lower on the food chain of this industry to the OEM component makers.

Many industry pundits like to repeat the adage that; "the network IS the computer." Well, what if this was literally so? Imagine a computer divided into its component subsystems, each in its own little self-powered box and each with it's own largely self-contained firmware based system software making it function rather like a so-called 'smart' peripheral; a CPU with RAM, a mass storage unit, a user interface device like a PAD (personal access display), various peripherals like printers, special mass storage devices like DVD-RW and tape drives, and a network management unit like a kind of router/switch for the network which functions as a system bus to tie them all together. Now suppose this network were wireless or run on a single thin cable. And suppose there could be any number of these subsystem modules operating simultaneously in the same 'system domain.'

This would, at first, seem like a backward step in design. After all, the personal computer industry was founded on the idea of miniaturization, consolidating the discrete subcomponents of earlier mainframe and minicomputers into a small package. Why reverse this? In fact, this Distributed Computer wouldn't take up any more or less space than a conventional personal computer. The big difference, though, is that now you have virtually unlimited flexibility and scalability and the freedom to put parts that don't require physical contact with the user out of the way, in desk drawers, in a closet, under the floor, or inside the walls. All the user physically needs to be in routine contact with is PADs and since these don't need to carry any other hardware than is necessary for the job of user interfacing and linking to the network they can be much more light and compact, much more solid-state, and much more durable than any current portable computing devices. But most importantly, the computer as a whole has no fixed limits on scale or configuration. It can have as few or as many modules as needed under the same system domain space and they can be distributed anywhere; throughout a room, throughout a home, throughout a building, or all over the globe. It's a computer that effectively has no off switch because, like a network, it would dynamically configure to whatever specific mix of module 'nodes' happened to be on or off at any time. It's alive as long as at least one system network router/switch module is on and it could turn other modules on and off on demand. And the modules don't become obsolete the way common personal computers due now because they are not locked together. If one piece of hardware fails or becomes obsolete it has no effect on the functionality of the rest of the components and can be simply replaced by itself. Even the system network infrastructure could be made replaceable independently of the rest of the hardware assuming one makes very compact plug-in network interfaces for them. Also, one can grow one's computer as big as one's needs. Need more processing performance? You can either replace the CPU with something faster or just add more CPUs. Don't need all that power all the time? Have the CPUs you aren't using left powered down until needed.

How could such a Distributed Computer be made to work? The typical conventional microcomputer relies on a monolithic operating system which parallels the monolithic nature of its hardware. Firmware in a 'boot ROM' commonly called a BIOS functions as a bridge to interrogate the system bus and sense structure of the hardware and plug-in expansion components, sets up a table in RAM (and sometimes SRAM) that defines the logical addresses of all the 'address vectors' for the devises plugged into the machine, then bootstraps the system software from fixed default locations on built-in mass storage. Well, the Distributed Computer would work similarly except that its 'BIOS' consists of more intelligent 'kernels' that run inside each component module and basically have them pre-. The task of sensing the state of the hardware is a continuous process run by the network controller modules -which are effectively the lowest logical level of hardware in the system. Their kernels and built-in microcontrollers maintain the tables that define the configuration of the system hardware in regular communication with those other modules. In a typical personal computer the interface between system software and peripherals like mass storage devices and video devices is very low. The devices are effectively 'dumb' components that require continuous attention from the system software. In the Distributed Computer these modules are 'smart' devices whose built-in kernels and microcontrollers perform all the direct control of the mass storage devices they contain in response to high level function calls. This makes for a more reliable system because the firmware based kernel can't 'break' like conventional software often does and thus inadvertently damage or corrupt file data. Similarly, security is better because mere software can't surreptitiously circumvent the firmware to assume control of these storage devices.

The CPU modules would feature a kernel similar in nature to the traditional UNIX kernel in that its primary function is the management of protected RAM partitions, the loading and running of programs, and the cluster-style inter-CPU communication which would allow any number of CPU modules in the system domain to function collectively like a single logical CPU. But the Distributed Computer would feature one very significant difference. In order to isolate the manufacturer's choice of processor hardware from the standard protocols of the system domain, the Distributed Computer's kernel would include a kind of byte-code interpreter intended to establish a universal machine code independent of the specific machine code of the microprocessors used. Just as with the motherboard level architectures of common personal computers, the choice of proprietary machine languages on the part of microprocessor manufacturers is largely a gimmick intended to secure market share through deliberate incompatibility. It's true that often these chips -especially CISC chips- feature unique capabilities which can only be expressed in unique code functions but with the trend in computing generally favoring RISC processors the importance of such things has greatly diminished. Most RISC CPUs have very little, if any, effective difference in command functions among their sets of machine codes. So it's effectively difference for difference sake, again. Since the Distributed Computer is intended to be independent of all possible manufactures so that the vast community of OEM component makers are free to compete equally in system module development it needs a way to allow those manufactures to use any microprocessors they wish while still maintaining compatibility. This is achieved by having the CPU kernel run a byte code interpreter that effectively translates the the different microprocessor machine languages to a single common system language -perhaps something like Java. In effect the colective group of CPUs on-line in the system domain function rather like a contemporary network application server except that the 'application' they all run is the Distributed Computer's own byte interpreter. That interpreter is like a 'meta-application.' Ultimately the demand for performance may compel chip manufacturers to stop folling around and develop families of chips which run the byte code as their default machine language -something which, in fact, has been done in the past for very specialized computers. There have already been SmallTalk, LISP, Java, Basic, Fourth, and other processors.

The highest logical level of hardware in the Distributed Computer system domain is the PAD or user interface module. It's also the most sophisticated piece of hardware in that it has the most sophisticated kernel and microcontrollers. Again, in a typical personal computer system software -in conjunction with application software- assumes all the tasks of generating a user interface through direct control of video, audio, mouse, keyboard, and other devices. Indeed, this is one of the most process-intensive functions for system software. And all these user interface devices are treated by as discrete peripherals. In the Distributed Computer the PAD is assigned most of this work with its discrete user interface devices lumped together in a single package. System software doesn't deal much with it at all and applications communicate with the PAD at a high level. It is rather like the X-terminals once popular with UNIX based systems or like a firmware based Web browser. Because the PAD has much more intelligence, including a fair compliment of RAM and a functional CPU, it is potentially the most self-contained of the system components and can function 'off-line' like a portable computer. Some PADs would be fashioned specifically for this dual capability, including their own compact mass storage just like laptops and PDAs today. But PADs have a potential infinite diversity, their form optimized to specific applications. This is critical to the Distributed Computer's ability to integrate diverse digital media. There could be a terminal-like desktop PAD, tablet PDA like handheld PADs, drafting table PADs, wall TV PADs, pocket audio PADs, cell phone PADs, PADs inegrated into appliances or vehicles, even toys and robots. And all of them could be in the same system domain, the same personal computer. No existing personal computer could realize such flexibility.

As we can see, there seems to be very little left for a conventional operating system to do in this Distributed Computer's system environment because so much of the traditional OS functions would now be incorporated into the respective firmware of each module. This is a deliberate feature. In effect, the Distributed Computer would need no OS in the conventional sense. Instead, it need only include a set of core software components which establish a framework for the user interface metaphor creating -in conjunction with the kernels of PADs- the virtual environment the user sees his files, programs, and devices in. The logical choice for this would be a document oriented component software environment where the collective device kernels establish a default 'system document' like a portfolio of virtual control panel pages into which other application and user document pages 'plug-in'. I devised just such a system with the development of the Tapestry environment for the JoeyPAD portable computer -the JoeyPAD designed as an introductory PAD to transition users toward the concept of the Distributed Computer. Tapestry would build on an XML and Java core that effectively turns XML into a self-contained component software environment where, instead of vast collections of disconnected discrete Web files, one has a single database which can move document and embedded software/media elements around. In other words, Tapestry consists of a kind of advanced XML database that treats all software as 'children' of a 'parent' system document. One never treats data as 'files' in this environment but rather as document pages, page sets (books), code and media objects which are moved from the system document of one system domain to another.

In effect, what the Distributed Computer represents is a kind of dynamic coalition of network appliances which create a kind of virtual personal computer embodied by the system domain. It's as if you had a personal Super-Internet formed by this collection of devices that function almost like network servers but perform more elemental functions. If this seems like a highly unlikely concept to ever be realized, think again. Even though I may be the only person to have comprehensively defined this technology, it is nonetheless beginning to come into being on its own as a result of the current trends in evolution of Internet hardware products. We already have a steadily growing assortment IP based network appliances on the market now which function very much like the system I've just described but not in a coherent way. Each possessed of their own microcontrollers serving Web based user configuration pages, they are like crude prototypes of the Distributed Computer modules I've described here. We lack only two types of appliances to complete the package; a generic CPU appliance and a comprehensive PAD. Thus I have become convinced that this is the likely form of personal computing in the near future.

But there is yet another technology which promises to take this concept to an even higher level; the Virtual Computer. In the 1980s there emerged an interesting new class of chip device intended to serve the market of remote telecommunications systems. Known as the Field Programmable Gate Array (FPGA), this device consisted of an array of PROM whose contents defined the logic function and connections for an array of gate cells. In effect, this device allowed you to make any logic circuit you wanted, within the limits of its capacity, simply by loading the appropriate table of data to define it into PROM. This proved to be very useful in remote communications devices -such as one might have along an undersea cable or on some inaccessible telecom tower- which could effectively be reconfigured on demand by remote control. But soon a handful of engineers and computer scientists began to realize there was another even more powerful potential in this technology. In theory, a large enough array of these FPGA chips could function as a computer by loading virtual circuits instead of programs. What's so great about that? Imagine if every function your average computer program did could be done IN ONE CLOCK CYCLE. FPGAs are relatively cheap and have relatively slow clock speeds. But because every program they run completes a process in a single cycle they realize incredible performance compared to conventional microprocessors. Furthermore, these devices overcome Ahmdal's Law. Ahmdal's Law states that the performance of a parallel processing computer cannot increase in proportion to the number of processors because increasing their number simultaneously increases the volume of program code that must be pushed through the system. This is no problem for FPGAs because they don't 'run' program code. Their circuits just process data straight out of their assigned RAM. They only encounter Ahmdal's law in respect to the limit in bandwidth of the system bus, which has no effect on parallel processing performance, just the rate of speed the data gets pushed to the individual processing circuits. It's no surprise this technology has attracted a host of enthusiasts who have come to refer to systems based on them as Virtual Computers. Almost all mainstream computer companies have experimented with them and there's a whole computing subculture today working with these devices but largely going un-noticed by the industry media.

So why are we not seeing these devices in any powerful new computer products? (aside from network devices like router/switches) Three reasons. First, to make programs that exploit this technology means being able to compile conventional software into logic gate structures. This is something few programmers today have the talent to do and so far no comprehensive direct compilers have been developed, although there are some rudimentary C compilers capable of handling simple processes. The whole idiom of 'program as dynamic logic circuit' is very alien to contemporary programming theory and may require some new language paradigms to be developed. Next, because chip manufacturers still regard FPGAs as a niche product, they have yet to put much effort into expanding the cell capacity of the devices. Their capacity slowly but steadily improves -thanks largely to demand crated by their use in routers- but a comprehensive computer using this technology is basically replacing both CPU, RAM, and quite a few peripherals chips with FPGAs and the devices do not come close in cell capacity that would require. Finally, FPGAs lack one very critical capability; the ability for circuits in the gate array to address the PROM array that defines their state. This is a very critical capability because in order to dynamically load and unload software the system needs to be able to run circuits which can rewrite other circuits. Without this capability the current experimental Virtual Computers all rely one a separate conventional computer to load and change their software. They function like co-processors to these conventional computers. It remains to be seen when these critical improvements of the technology will emerge. There are no technical obstacles. The obstacle is the manufacturers who, after almost two decades, still don't get it. Or perhaps they do get it and are afraid of the potential this technology has to obsolesce microprocessors as we know them. After all, the comparison of microprocessors to Self-Addressing Gate Arrays (SAGAs) is effectively like comparing clockwork to the microprocessor.

But should such technology finally emerge, the effect it would have on the technology of the Distributed Computer (let alone all other digital devices) would be dramatic. Virtually all non-hybrid ICs (that is, devices combining analog and digital circuitry) in all computer devices could be replaced by the combination of SAGAs and EPROM.(for default firmware) In effect, most hardware would be replaced by software. Clusters of CPU modules could be replaced by an individual SAGA module which, rather like traditional industrial computers, expands in capacity by plugging in identical SAGA page boards into a passive backplane. One would only desire multiple CPU modules where there is a need for redundancy in the hardware, in case one module physically breaks down but still leaves the others on-line, again reinforcing this idea of a computer with no off-switch. But this could also be achieved just as readily at the backplane level, as in the case of many hot-swap modular high reliability computer systems today. The need to run a byte-code interpreter on the CPU modules would be eliminated because all machine code would be replaced by the generic gate definition language of VRML. Software components would be akin to image files in structure and could be much more compact than software today, especially since they could incorporate runtime compression that, again because of the nature of the SAGA technology, decompresses as fast as its loaded. The low cost of the technology would basically allow people to have SAGA array capacities as large as they physically have space for -which considering the space current power users give to their systems could mean CPU modules as big as a refrigerator hidden away in closets. The performance of these machines would be almost impossible to imagine. Currently small single-board co-processor FPGAs running discrete tasks readily match the performance of the most powerful supercomputers running at clock speeds of mere tends of hertz. SAGA chips advanced to current SRAM clock speeds and capacity would be able to run comprehensive software at speeds beyond the most poerful of current supercomputers. And those power-users with closet sized SAGA arrays would basically have the computing capacity of higher mammal brains at their fingertips.

So there you have it. My personal vision of computing in the 21st Century. Will it turn out as I expect? Since I have no ability to push it along myself we will just have to wait and see. But so far my ability to predict trends in the computer industry has been pretty good. The only significant error I've made to date was over-estimating the ease of acceptance of tablet computer technology and calling too early the introduction of practical PADs, basically because I couldn't imagine any computer maker being so stupid as to introduce such products without also introducing the comprehensive document oriented system environments to back them up. There seems to be a chronic failure to grasp the obvious in the computer industry today. Our contemporary digirati seem largely oblivious to the inconvenience of current products and largely ignorant of the full spectrum of technology they have at their disposal.