My investigations start off with the human input, the keyboard, and an application, personal (as opposed to business) word processing. With this starting point, we form a branching trail through the woods of possibilities.
Macintosh will have a typewriter styled keyboard with embedded numeric pad (as on the HP 2621). No separate key pad should be provided for three reasons: it shaves a bit off the cost, it makes the package physically smaller, it looks less forbidding. Such a keyboard is excellent for word processing, and we will first explore system requirements for this application. Aside from the embedded numeric pad, the keyboard layout will not differ much from Sara's excellent design.
The cost of such a keyboard will be about $20.
A practical word processor has either a buffer of over 20K bytes for user input, or a mass storage device whose operation is totally invisible. Since an overflow of the internal buffer can happen while a person is typing (even in the middle of a word), the time that the keyboard does not respond while the system is squirrelling away the buffer should be under 0.1 second. You don't want the system breaking the user's concentration by upsetting him or her with random pauses.
Since this application places some restrictions on storage, there are (at least) two ways of going about it: supplying sufficient random access storage, or a fast mass storage device.
This can be provided through RAM, or through some other technology such as bubble memory. For our application, we have said we need a minimum of 20K bytes for the user's area (there being no real upper limit on how much user storage can be put to use). In addition we need the word processing software, and the underlying operating system. Here the path forks again, as the amount of storage required for the software depends on the CPU chosen. If the CPU is a Lisa type, then the software will probably require about 10K bytes, and the system need only have 32K bytes altogether. If the CPU has the power of, say, a 6809, then the interpreter will require perhaps 8K, the word processor about 10K and the operating system around 8K bytes. This CPU would require 46K bytes. If 16K bytes of RAM cost $25, (a 6809 costing about $10) the Lisa type processor would have to be under $35 to be cost effective in this application.
In the Macintosh time frame, the only viable mass storage is floppy disks. Hard disks are too expensive, and their media is not removable. Bubbles seem to be coming along a bit too slowly. Nonetheless, we will keep our eyes open.
While floppies are usually considered to be too slow for our application, they can be fast enough if we go to a multiple processor system so that spooling can go on in parallel with word processing. Assumming (and here is another branch in the path)24 lines of 64 characters (1536 bytes) there could be a minimum 2K buffer which both refreshes the screen and is the text buffer. When it scrolls off screen, it scrolls onto a floppy. The few hundred extra bytes gives the system enough time to start up the disk drive.
Searches might, with this kind of scheme, be a bit slow and noisy. There are many trade-off points, the buffer can be expanded to 4K, or 8K, or larger, and the disk useage goes down with each increase in memory. A mathematical model can be built for this situation.
Assume that the user has M kilobytes of memory at a cost of $b per kilobyte, a floppy (and associated processor and support circuitry) which costs $f with a transfer rate of T seconds per kilobyte, and a processor and memory that permits a search for a pattern match at a rate of G seconds per kilobyte in a document of D kilobytes (D*G seconds for the complete document when the entire search is in memory). We can now examine how many kilobytes per second of searching a system can achieve with disks, and what the cost is for different memory/disk tradeoffs.
If
D <= M
then no disk accesses are required, as the entire document fits in memory so that the time required for the search is
D*G
at a hardware cost of
Mb.
In the case
D > M
where there is insufficient main memory for the entire document, disk accesses occur. Assuming again a search through the entire document, the number of accesses (less one) is S which can be calculated by S = TRUNC (D/M). The time for reading in each segment except the last is L + M*T, where L is the latency time of the disk. The last segment is of length D - S*M (which is 0 if D MOD M = 0). For the total number of accesses the time is S*(L+M*T) + L + (D - S*M)*T. To this is added the in-memory search time, D*G. Simplifying the resultant expression, the total search time is
D*(G + T) + L*(S + 1)
which is easily interpreted in this form: the first major term represents the total time for transferring and searching the document, the second term represents the sum of the latency times.
The cost of the hardware is the memory cost plus the floppy cost
(M*b + f).
This model must be modified where, as on our floppies, the latency time is significantly lower if the disk is already spinning. In this case
L = U
where U is the motor-starting latency and
L = V
where V is the rotational plus average seek time latency. Usually the time V is included in U in the motor-starting case. There is also a fixed shut-down time, W.
The time for a search through a complete segment is (D*G)/(S + 1), so that if this time is greater than or equal to W, then
L = U
otherwise
L = V + W - ((D*G/(S + 1)))
which is the rotational plus seek latency, plus what is left of the motor-off time after the search is complete. This ignores the very small program overhead in the spooling algorithm.
A concrete example in the late 1981 time frame might have the floppy (and associated hardware) at $55, and memory at $1.60 per kilobyte. Assume that the transfer rate averages 0.1 seconds per kilobyte (this is the present Apple II 16 sector speed), and that a search in memory takes .006 seconds per kilobyte (this is about the speed at which Sara will work). Assume further that the latency U is 1.0 seconds, and the average latency V is 0.15 second (on the Disk II, the average rotational latency is 0.1 second, and a track to adjacent track seek about 0.01 second).
The reader is directed to the programs M 9 and M 10 in this series of documents to play with these values.