DistOS 2014W Lecture 4
The Alto (Jan. 16)
Discussions on the Alto
CPU, Memory, Disk
CPU
The general hardware architecture of the CPU was biased towards the user, meaning that a greater focus was put on IO capabilities and less focus was put on computational power (arithmetic etc). There were two levels of task-switching; the CPU provided sixteen fixed-priority tasks with hardware interrupts, each of which was permanently assigned to a piece of hardware. Only one of these tasks (the lowest-priority) was dedicated to the user. This task actually ran a virtualized BCPL machine (a C-like language); the user had no access at all to the underlying microcode. Other languages could be emulated as well.
Memory
The Alto started with 64K of 16-bit words of memory and eventually grew to 256K words. However, the higher memory was not accessible except through special tricks, similar to the way that memory above 4GB is not accessible today on 32-bit systems without special tricks.
Task Switching
One thing that was confusing was that they refer to tasks both as the 16 fixed hardware tasks and the many software tasks that could be multiplexed onto the lowest-priority of those hardware tasks. In either case, task switching was cooperative; until a task gave up control by running a specific instruction, no other task could run. From a modern perspective this looks like a major security problem, since malicious software could simply never relinquish the CPU. However, the fact that hardware was first-class in this sense (with full access to the CPU and memory) made the hardware simpler because much of the complexity could be done in software. Perhaps the first hints of what we now think of as drivers?
Disk and Filesystem
To make use of disk controller read,write,truncate,delete and etc. commands were made available.To reduce the risk of global damage structural information was saved to label in each page.hints mechanism was also a available using directory get where file resides in disk.file integrity a was check using seal bit and label.
Ethernet, Networking protocols
Although the original motive of Alto as a personal computer was to serve the needs of a single user, it was figured out that communicating with other Alto’s/computers would facilitate resource sharing – for collaboration and economic reasons. The main design objectives for the computer network connecting personal computers (Altos) were:
Data transmission speed: Bandwidth which should at least match the memory bus speed to give the end user a consistent notion that the resources accessed over the network should also have the same latency as compared to resource accessed within the computer
Size of network: Capability to connect large number of nodes together
Reliability: Once the user starts to use resources/service over a network it is vital to ensure that the network is reliable enough so that the user gets the quality of service required.
Alto uses a general packet transport system which can be thought of as a set of standard communication protocols towards facilitating interoperability.
The key element enabling the communication system between Alto and other computers was the Ethernet, a Layer 2 protocol and mechanism developed in-house at Xerox by Robert Metcalf et al. Following are the characteristics of the Ethernet – Broadcast, packet-switched network with bandwidth – 3Mbits/sec which can connect 256 computers together, and allows up have a distance of 1 Km between two connected nodes. Another important aspect of Ethernet was new nodes/computers could be added/removed/powered-on/powered-off from the network without disturbing the already existing network communications. Since Ethernet offered only best effort service without guarantees for an error free service, towards achieving reliable communication over it a hierarchy of layered communication protocols were implemented in Alto.
Alto had the capability to act as a gateway connecting different networks together. Xerox had a “Xerox Internet” consisting of several hundred computers, 25 networks and 20 gateways providing internet service back in 1979.
Ethernet communications system had two components – Ethernet controller and transceiver. Ethernet controller performed the encoding/decoding, buffering and micromachine interfacing functionalities whereas the transceiver deals with the transmission/reception of bits, which operated in half-duplex mode.
One important different with respect to the design of the Ethernet controller task as opposed to the ones for display and disk were that there were no periodic events to wake this task up instead a S-group instruction was used to set a flip flop in Ethernet hardware which was used to wake up the Ethernet controller task. Also the Ethernet used interrupt based mechanism used to indicate completion since the packet reception/transmission happens asynchronously. Ethernet microcode implements a packet filtering mechanism which checks for the reception of (1) destined for the host (2) broadcast packets. It can also operate in a promiscuous mode with host address set to zero receiving all packets, which can be used for debugging purposes.
Ethernet had no security mechanism built into it. Since Ethernet was a collision domain an exponential backoff algorithm was implemented towards avoiding collisions (which occurs when two Ethernet transmitters tries to use the ether at the same time).
Graphics, Mouse, Printing
Graphics
A lot of time was spent on what paper and ink provides us in a display sense, constantly referencing an 8.5 by 11 piece of paper as the type of display they were striving for. This showed what they were attempting to emulate in the Alto's display. The authors proposed 500 - 1000 black or white bits per inch of display (i.e. 500 - 1000 dpi). However, they were unable to pursue this goal, instead settling for 70 dpi for the display, allowing them to show things such as 10 pt text. They state that a 30 Hz refresh rate was found to not be objectionable. Interestingly, however, we would find this objectionable today--most likely from being spoiled with the sheer speed of computers today, whereas the authors were used to slower performance. The Alto's display took up half the Alto's memory, a choice we found very interesting.
Another interesting point was that the authors state that they thought it was beneficial that they could access display memory directly rather than using conventional frame buffer organizations. While we are unsure of what they meant by traditional frame buffer organizations, it is interesting to note that frame buffer organizations is what we use today for our displays.
Mouse
The mouse outlined in the paper was 200 dpi (vs. a standard mouse from Apple which is 1300 dpi) and had three buttons (one of the standard configurations of mice that are produced today) which were stored as 8 bits in memory. They were already using different mouse cursors (i.e., the pointer image of the cursor on screen). The real interesting point here is that the design outlined in the paper was so similar to designs we still use today. The only real divergence was the use of optical mice, although the introduction of optical mice did not altogether halt the use of non-optical mice. Today, we just have more flexibility with regards to how we design mice (e.g., having a scroll wheel, more buttons, etc.).
Printer
They state that the printer should print, in one second, an 8.5 by 11 inch page defined with 350 dots/inch (roughly 4000 horizontal scan lines of 3000 dots each). Ironically enough, this is not even what they had wanted for the actual Alto display. However, they did not have enough memory to do this and had to work around this by using things such as an incremental algorithm and reducing the number of scan lines. There was only enough memory to print in bands, where each band was loaded in after the previous one was printed. We were disappointed that they did not actually discuss the hardware implementation of the printer, only the software controller. However, it is interesting that the fact they are dividing the memory requirements of the printer between the hardware itself and the computer was quite a modern idea at the time, and still is.
Other Interesting Notes
We found it interesting that peripheral devices were included at all.
The author makes a passing mention to having a tablet to draw on. However, he stated that no one really liked having the tablet as it got in the way of the keyboard.
The recurring theme of lack of memory to implement what they had originally envisioned.
Applications, Programming Environment
Emulation
A notable feature is that the Alto implemented a BCPL emulator in the PROM microstore. Other emulators were available, but they were loaded in RAM. BCPL was used as the main implementation language for the computer's applications. Very little assembly was used.
Programming Environments
The Alto ran the gamut of available programming environment. A conventional toolchain implemented in BCPL was offered (ie. compiler, linker, debugger, file manager, etc.) Interactive programming environments such as Smalltalk and Interlisp were also available. These fell pray to the Alto's limited main memory (64k) and suffered crippling performance issues.
The only standardized facilities for programming environments to use was the file system and communication protocols. All other hardware had to be accessed using custom methods.
Personal Applications
Applications made use of the display, mouse, and keyboard. They were mostly involved with document production. For example, there was a text editor where the user could specify formatting and typefaces. The PC also helped facilitate and automate aspects of logic board design and assembling.
Communication in applications
Most applications were designed with the assumption that the computer would exploit networked resources. For example, printing services would be handled by a printing server, file storage could be local or distributed. The Alto made use of existing services too. Its clock was set by a 'time of day' service and it could be bootstrapped over ethernet.
Communication in applications was also used in new and novel ways. For example, the debugger mentioned above was network aware. It could help programmers debug software remotely.