Edit K72

Title:

Last edited: 4:09:48 am on 4 December 2008 by bd231c40.virtua.com.br

!!!Inspiration and Motivation
The paper *"A Personal Computer for Children of All Ages">http://www.mprove.de/diplom/gui/Kay72a.pdf* by Alan C. Kay (In Proceedings of the ACM National Conference, Boston Aug. 1972) is an early description of the Dynabook concept. This will be referred to as simply "the paper" below.

Instead of what was described there, the non commercial Xerox Alto computer was built and served as an interim dynabook throughout the 1970s. Alan Kay's "Early History of Smalltalk" paper (in *html>http://gagne.homedns.org/%7etgagne/contrib/EarlyHistoryST.html* and *pdf>http://www.iam.unibe.ch/~ducasse/FreeBooks/SmalltalkHistoryHOPL.pdf*) for the second History of Programming Languages conference has more details about alternatives that were considered (see specially the "KiddiKomp", "Display Transducer" and "miniCOM") and what was actually built.

The question that this project tries to answer is: would it have been possible to build something similar to that described in that paper using
- technology available in the early 1970s
- knowledge available today?
This second condition eliminates any historical value from this project since such knowledge didn't exist back then. So it is not like a proper retro-computing project of rebuilding something exactly like it was (an old PDP-6, for example) or like it could have been (Babbage´s Analytical Engine, for example). But the question we are interested in is exactly if we have really learned important things in these 30 years. We imagine the device becoming available around 1975 or 1976, which will be referred to as simply "back then" below.

Some previous speculation along these lines in the Squeak email list in May of 2000 started with *a message by Jecel Assumpcao Jr>http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-May/019195.html* about if something like Smalltalk-72 could be made to run on the 4KB Altair, to which *Alan Kay replied>http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-May/011039.html* that the Altair was a dead end so this wouldn't be worth it. *Jecel mostly agreed>http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-May/009765.html* and explained the motivation for this speculation to which *Jan Bottorff added some comments>http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-May/004067.html* about the PC legacy infrastructure. Other messages in that thread were also interesting.

This *message>http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-March/055250.html* from Alan (in the middle of a thread with many interesting messages) from March of 2003 has more details about doing multi MOS processor machines.

There are no deadlines nor end points for this project.
!!!Architecture
As described in the paper, we would have a processor and several I/O chips connected via a bus to a shared memory. The paper suggests that there is no reason why the I/Os can't be processors themselves, so here we are proposing that all of the main chips are identical.
!!!Bus
There are 16 multiplexed address/data lines and two control lines called Row Address Strobe (RAS) and Column Address Strobe (CAS). This makes it easier to interface directly to DRAM memory chips, though a practical design will include some latches and buffers.

The first phase of the bus is when both controls are inactive. The data lines are used to determine which processor will use the bus next. Each processor pulls down a different data line (and a pull up resistor in each one keeps the others at a high level) and an algorithm implemented in each processor allows it to decide if it is the winner or not.

After this all processors release the data lines and the current bus user puts the first half of the address, the bank selection bits and the read/write bits on the data lines. Then the RAS is activated. The second half of the address goes on the data lines and after some time the CAS is activated. Then the data is transferred and both control signals are deactivated bringing us back to the arbitration phase.

The CAS cycle is normally repeated four times so that blocks of memory can be transferred more quickly than as four separate memory accesses. This might require that the bottom two bits of the column address be stored in a counter and the other bits in a latch.
!!!Processor
The paper speculates that the chips would  have around 8000 transistors. Access to the main memory is a major bottleneck, so there should be as much internal memory as possible.

A 16 bit design capable of addressing a large physical memory would be good enough to last well into the mid 1980s. Since this is an object oriented design there wouldn't be the same software hardships that the 8086 imposed on so many poor programmers.
!!Package
Most early processors used very large packages, with from 40 to 64 pins. These days they use hundreds of pins but that would have been impossible back then. The bus requires 18 lines all by itself, and we can suppose at least one pin each of ground and power. One or two pins would be needed for clocks (the 680X and 6502 used two phases externally). A reset signal might take up another pin, though it would be nice to avoid that if possible.

A good option would be a 28 pin Dual Inline Package (DIP). This would probably be ceramic initially, but eventually plastic might become an option. This would only leave around 6 pins for I/O, but that should be enough with some imagination.
!!Integrated Circuit Technology
CMOS technology was not a possiblity back then, being only used for very special applications such as digital watches. nMOS was the most popular among early microprocessors, though some used pMOS instead. Texas Instruments used the I2L bipolar technology instead in its bit slice and 9900 processors.

Many early nMOS circuits needed an additional 12V and a -5V power supplies beyond just the +5V. This would be a really, really good thing to avoid.

One interesting variation that was tried in the early 1980s was the clock powered nMOS technology, called *Hot Clock>http://caltechcstr.library.caltech.edu/archive/00000365/*. This required a much more complicated circuit to generate the signals that serve as both clock and as power sources for the chips (these clock generators were external circuits) but it resulted in power consumption similar to CMOS.

An interesting modern variation of this is *Clock Steered Logic using a Rotary-Traveling-Wave-Oscillator>http://www.multigig.com/technology/publications*. This also only uses nMOS transistors and powers everything from the clocks. The big difference is that the clock is generated internally.

In the 1970s the microelectronics lab (LME) at the University of São Paulo started using (I don't know if it was invented there) a trick to save on the number of masks needed to build an nMOS circuit. Each transistor had its gate in the form of a rectangle that separated the source (inside the rectangle) from the drain (the rest of the chip). This allows real circuits to be built with only a Polysilicon, a Metal and a Via mask. Only very simple circuits were built and the transistors were pretty large compared to the minimum geometry open alternatives, so it is not clear that a whole processor could have been done this way.
!!!Memory
We can safely ignore the first generation 1K DRAM chips and all their complex support circuits. So the first machines would use 4K chips, moving to the 16K in the late 1970s, 64K in the early 1980s and 256K in the mid 1980s. Beyond that we must suppose that newer processors would replace this design.

The paper talks about one bank of 16 chips of 8K each. So we would have two banks of 4K chips initially. But that doesn't seem like enough. The original Alto had four times as much and yet the lack of memory was its main shortcoming.

There would obviously be some ROM, at least enough for a boot code. But it would also be possible to store enough of the system in it to compensate for the lack of RAM, as was done in the original Macintosh.

The paper speaks of compression to save memory. This complicates writing to objects since that changes how much they can be compressed but some scheme could be developed. In fact, having a system that allows changes to be stored separately from the main object would be a good idea for ROM based objects. Research on *compressed heaps>http://www.cs.utexas.edu/users/oops/compressed-caching/index.html* would certainly help here.
!!!Low Speed Peripherals
The main processor, the one that executes the user's code, would be responsible for dealing with the keyboard, mouse and other such devices. Here it would be possible to use the "poor man's USB" implemented in the Merlin 1 computer. That had a port with power, ground, latch, clock and data in signals (the computer could only read from peripherals but not write to them). All of the peripherals were implemented with low cost TTL circuits. An improvement would be to pulse the power line for the clock and use timing (no clocks for 1 ms, for example) to send an implied latch command. That would need only three pins.

The connector would have a male part to attach to the computer and a female part to allow the next peripheral to be attached to the same port. Four wires would go from this connector combo to the actual device (power/clock, ground, data out, data in).

A diode and a capacitor would be enough to get a good power source from the power/clock input and a 555 monostable circuit could generate the latch signal. The first four bits shifted out of a device would indicate the type of device (keys, displacement, ADCs, etc) and the next four bits would say how many bytes of data should follow.
!!!Video
While color is very desirable, it would not be really practical until the mid 1980s. So this design should support only black and white. Though the four level NeXT was rather nice. A simple bitmap is the simplest option, but it isn't reasonable for that to take up more the 1/4th of the main memory. Yet even a mere 320x240 needs 9600 bytes, which is over half of the memory suggested in the paper. A display with persistent images could be its own display buffer, however, freeing main memory entirely from that task.
!!Display
Even today it is very complicated to find a flat panel display that is both good and low cost. It would probably not have been possible to do a flat panel back then, so a CRT seems like the only option. A small one would still enable a portable computer like the NoteTaker, though not a real Dynabook. A really small tube with some kind of projection system might be interesting since it allows for electrostatic deflection but it might not be possible to make it bright enough so that the expanded image is still visible. Very early computers used CRTs as memory devices and some osciloscopes had a storage option, so a persistent display as mentioned above might be possible.
!!!Network
The obvious option would be the Ethernet, even though it didn't exist yet when the paper was written. Even in the 1980s twisted pairs still meant the StarLan, a 1Mbps version of the Ethernet. People considered shielded twisted pair cables to be too expensive and so designs normally were forced to use simple telephone wiring instead.

A ring based "register insertion" network could be an alternative. Without complicated bypass circuits, all machines in a ring would always have to be operational for the network to be used. A simple hub in a "ring of rings" topology would eliminate this restriction when needed.
!!!Mass Storage
The endless tape mentioned in the paper was also seriously investigated for the Pegasus project in 1983 and was used in the Sinclair QL machine. The latter can't really be considered a success. For Pegasus it was decided that it was better to not include mass storage in each machine but use the network to access servers (the teacher's machine in a classroom setting) which could have much nicer disks.
!!!Software
Smalltalk, obviously. But there are many details to figure out.

- lock this page
- enter new password
- reenter same password

Send e-mail alerts to these addresses upon next save: