Page Numbers: Yes X: 530 Y: 10.5" First Page: 22
Line Numbers: No Modulus: 5 Page-relative
Heading:

Programmer’s Guide to Orbit, the ROS Adapter, and the Dover Printer

2. ROS Adapter

The ROS adapter is a general-purpose interface between EIP’s (Electronic Image Processors; Orbit is one) and raster-scanned output devices. The motivation underlying its design is that one adapter can serve to connect the "9-wire ROS interface standard" to a number of similar ROS devices. There are two slightly different versions of the adapter. Dover systems come with a "TTL adapter," hereafter abbreviated T. A high-speed version of the adapter has been built by SDD using MECL 10K logic, called the "MECL adapter," hereafter abbreviated M. In mid-1978, the T adapter was redesigned, with a few minor "visible" effects. This revision will be referred to as the "Dover II" adapter.

The adapter contains logic to control fully the raster output scanner (ROS) itself, including of course generating a video signal. It also contains a mechanism to receive printer commands from the EIP and forward them to the printing engine, as well as a mechanism for receiving engine status and forwarding it to the EIP. (The standard Orbit microcode provides access to the adapter with the ProgramROSCommand and ProgramROSStatus functions.)

2.1 Basic imaging technique

The EIP delivers raster images of pages to the adapter, which is responsible for formatting it properly on the output device, and for timing signals properly. The adapter is basically a massive synchronization aid: it receives timing information from the printing engine and the ROS equipment, and generates requests for video data (to the EIP) in order to keep up. The video data it receives must be converted into a serial video signal, timed properly with respect to the scanning motion, so that the image appears in the proper location on the "page."

A simple conceptual model of the imaging process will help in the discussion of the rather intricate chores of the adapter. Although the model is somewhat oversimplified, it includes the basic ideas common to all the devices that the adapter can drive. Figure 2-1 shows the model schematically: there is a single scanning beam that scans in a fixed plane, under which a continuous sequence of "page image frames" is being moved. If we properly time the modulation of the scanning beam, we will leave behind within each page image frame an image that corresponds to the raster prepared by the EIP. A number of timing problems must be solved for this to happen properly.

Engine operation. The printing engine reports a signal PrintMode to the adapter whenever its drive motors are running: this indicates that "page motion" in our conceptual model is in progress, even though pages may not be flowing under the ROS beam yet.

Page timing. We will need to know when the leading edge of a page image frame passes under the scanning beam. It is at this instant that we must begin acquiring raster data from the EIP and using it to modulate the scanning beam. This timing information can only be acquired with the help of the printing engine itself, for it is responsible for sequencing pages. The engine generates a signal called PageSync some fixed time before the page frame passes under the beam. Once inside the adapter, this signal is delayed to generate a timing signal called SendVideo which is true while a page image frame lies under the beam, and false in the inter-page gaps. The adapter will process EIP raster data only when SendVideo is true.

On the M adapter, SendVideo is named "DelayedPageSync" for historical reasons.

We mentioned above that Orbit needs to write the first few bands of raster information in a spot that will not be visible on the page, as they may contain garbage that has accumulated because refreshing has not occurred. In this case, Orbit should arrange to have SendVideo occur slightly before the actual page frame would pass under the beam.

The normal sequence of events, then, is roughly as follows: (1) The EIP issues commands to the printing engine to start pages feeding. (2) The EIP waits for SendVideo to disappear (the reason for this will appear later). (3) The EIP resets the adapter buffer mechanism and starts generating raster data. (4) When SendVideo becomes true as the first page frame passes under the beam, the adapter will begin requesting raster data from the EIP, and continue to do so as needed to control the beam modulation. Now one of two things can happen: (5a) SendVideo falls, signaling the end of the page frame. The adapter will cease requesting data from the EIP. Or (5b) the EIP refuses to honor a data request from the adapter, in which case the adapter will simply repeat the last data it received until SendVideo goes false. (6) To print the next page, the EIP returns to step (2), and may also need to contract with the printing engine to keep feeding paper. The reason for step 2 now becomes clear: without step 2, situation 5b might cause video for the next page to appear at the trailing end of the current page, because SendVideo is still on.

Scan-line timing. An even more intricate timing problem is posed by the scanning beam: we must carefully synchronize the video signal generated by serializing the raster data coming from the EIP so that it appears at the proper position along the scan-line. This involves two issues: (a) determining how to divide the scan-line into units that will correspond to each video bit, and (b) determining the absolute time at which video bits should be passed to the beam modulator.

A servo system and two detectors are used to solve this problem. The scanning beam passes first over a "start-of-scan" (SOS) detector, then over the page image frame, and then over an "end-of-scan" (EOS) detector. This sequence is repeated very fast: soon after EOS is generated for one scan-line, SOS for the next scan line occurs. The adapter divides the time between SOS and EOS into equal intervals (the exact number of intervals is a parameter set by the EIP): each one will correspond to one bit of video information. So now we have divided the scan-line into "bits."

The EIP generally produces raster data only for the portions of scan-lines that correspond to regions of activity on the page: the adapter is expected to supply "white" margins above and below this active region. Consequently, the adapter will need to know how the video data supplied by the EIP should be placed within the scan-line. The adapter implements a "bottom margin" by a counter that is started at SOS with a value specified by the EIP, and counted as "white margin" bits are sent to the modulator. When the count becomes 0, video data from the EIP is sent to the modulator, and continues to be sent until an "end of scan-line" indication arrives with data from the EIP. Thereafter, the adapter supplies "white margin" bits that will correspond to the "top margin."

Note: The number of bits of raster data provided by the EIP for each scan-line must be a multiple of 64. (With Orbit, this means that FA must be a multiple of 4.)

The servo that synchronizes scan-lines requires SOS and EOS pulses to arrive. Consequently, the adapter control must arrange that the laser beam is "on" as it passes over the detectors, or a pulse will be missed. When the servo is operating in equilibrium, the adapter ensures that the beam will be on for the detectors by anticipating where the beam is. However, in order to get the servo going initially, the beam must be completely on for a short while. This is accomplished by turning the beam on whenever PrintMode is true but SendVideo is not, i.e., in the inter-page gaps and while the engine is cycling up. This has the added virtue of "writing down" the photoreceptor in unused areas, thus preventing toner dumping.

Motor speed. The speed of the motor that drives the scanning polygon is carefully controlled by a frequency synthesizer. The adapter provides the basic timing signal to which the electronics locks the polygon motor.

2.2 Parameters

All of these timing and synchronizing features are governed by parameters that can be set by the EIP. Some of the parameters can be related by physical observations. The next few paragraphs are intended to provide enough information to permit calculation of the parameters!

Let us first define some parameters of the output image:

SThe number of scan-lines per inch on the page
BThe number of bits per inch along the scan-line

Now define some parameters of the ROS and printing engine (see section 3 for the values applicable to the Dover printer):

pPaper speed, measured in inches per second
fNumber of facets on the polygon
rNumber of polygon motor clock pulses/polygon revolution
dDuty cycle (i.e., SOS-EOS time/SOS-SOS time)
hEffective distance between SOS and EOS detectors,
measured at the paper surface.

From these we will need to calculate the relevant adapter parameters (ranges are given in parentheses):

MotorSpeed (0 to 4095)
MotorScale (0 to 7)
BitClock (0 to 4095)
BitScale (0 to 7)
LineSyncDelay (0 to 4095)
PageSyncDelay (0 to 4095)
VideoGate (0 to 4095 -- T version only)

We need to define two parameters that differ on the different adapter versions.. The first is bcMax, the maximum frequency of the bit clock. The other is crystalClock, the frequency of an internal adapter timing oscillator.

M versionT version
bcMax90 * 10630 * 106
crystalClock25 * 10612.5 * 106

Define a function Scale(x)=2x.

Now we can calculate the scanning motor speed in revolutions per second:

MotorRPS = crystalClock * Scale(MotorScale) / ( r * (4096-MotorSpeed) * 28)

Consequently, we can get the number of scan-lines per inch:

S = f * MotorRPS / p

These two equations allow us to determine MotorSpeed and MotorScale settings from the desired value of S.

The scan-line control is somewhat more complicated. The basic servo is controlled by the relation:

B = 4 * (4096-BitClock) / h

The peak bandwidth required from the adapter (and consequently from the EIP as well) is:

BitRate = f * MotorRPS * B * h / d

bits per second. (If Orbit is driving the adapter, it can deliver at most 23 * 106 video bits per second.)

An important side condition governs the setting of BitScale so that the bit clock servo operates in a reasonable range:

1/2 < 27 * BitRate / (bcMax * Scale(BitScale)) < 1

The remaining parameters are more easily calculated. LineSyncDelay is simply (4096-n/4), where n is the number of bits of white margin to leave at the bottom of the page (after the SOS detector). PageSyncDelay is (4096-n/i), where n is the number of scan-lines to pass up after receiving PageSync from the engine before starting SendVideo, and i is 1 for Dover II adapters, 4 for older ones. And VideoGate is (4096-n/4), where n is the number of scan-lines to pass up after SendVideo starts before stopping SendVideo (on the M adapter, VideoGate is not provided, and the falling of SendVideo is controlled by the printing engine).

2.3 Adapter commands

Control of the adapter, ROS and printer is accomplished with 16-bit commands. The high-order 4 bits of the command give a command code; the remaining 12 bits are used as an argument to the command. The command codes are:

0Buffer reset.

1Set scales.
BitScale ← command[4-6]
MotorScale ← command[7-9]
ExtendVideo ← command[10] (T version only)
TestPageSync’ ← command[12] (should normally be =1)
CommandLocal ← command[13]
CommandBeamOn ← command[14]
TestMode ← command[15]

2Set bit clock register.
BitClock ← command[4-15]

3Set motor speed register.
MotorSpeed ← command[4-15]

4Set line sync delay register.
LineSyncDelay ← command[4-15]

5Set page sync delay register.
PageSyncDelay ← command[4-15]

6External command 1 (forwarded to printing engine)
ExternalCommand1 ← command[4-15] (a register is set)

7External command 2 (M version only)
ExternalCommand2 ← command[4-15] (a register is set)
Set video gate (T version only)
VideoGate ← command[4-15]

10b-17bSpare

2.4 Adapter status

The adapter constantly reports 256 status bits to the EIP. These bits are normally viewed as consisting of 16 16-bit words. The first 8 words of status are reasonably independent of the kind of adapter (T or M) or the exact kind of printer attached to the adapter:

WordBitsFunction

0Special status from the ROS
0SendVideo (sometimes called DelayedPageSync)
1PrintMode
2Local
3BeamEnable
4StatusBeamOn
5StatusPowerEnable (M version only)

1Command register
0-15A copy of the command most recently received by the adapter

2Bit clock
0VideoPolarity (the setting of a switch)
1-3BitScale (register set with command code 1)
4-15BitClock (register set with command code 2)

3Motor speed
0SelectLeadEdge (the setting of a switch)
1-3MotorScale (register set with command code 1)
4-15MotorSpeed (register set with command code 3)

4Line sync delay
0Switch3 (the setting of a switch)
2ExtendVideo (register set with command code 1 -- T version only)
3TestPageSync’ (register set with command code 1)
4-15LineSyncDelay (register set with command code 4)

5Page sync delay
0Switch4 (the setting of a switch)
1CommandLocal (register set with command code 1)
2CommandBeamOn (register set with command code 1)
3TestMode (register set with command code 1)
4-15PageSyncDelay (register set with command code 5)

6External command 1
0LineNoise
1CompareError
2BufferUnderflow
3PacketsOK
4-12ExternalCommand1 (register set with command code 6)

7
0-3LineCount
4-15ExternalCommand2 (register set with command code 7; M version only)
4-15VideoGate (register set with command code 7; T version only)

The remaining 8 words of status are normally used for external (engine) status of various kinds. The TTL adapter organizes these words as follows:

WordBitsFunction

80-15Special status bits 0-15 (see Dover section for interpretation)
90-15Special status bits 16-31 (see Dover section for interpretation)
100-15ID (16 bits). This identifies the engine type.
110-15Serial number (16 bits). This specifies the serial number of the engine.

12-150-15Additional engine-dependent values, used by some printers (not Dover).

2.5 Additional adapter features

There are a number of additional adapter features, chiefly for providing various kinds of diagnostic and debugging help.

The ExtendVideo flag (T version only) can be used to override the action of the VideoGate counter. Once SendVideo comes on, it will stay on until ExtendVideo is turned off and then the VideoGate counter reaches zero.

There are two variations of "local" operation for checking out the printing engine. The machine may be switched to Local by a switch on the engine (and reported as a status bit), or may be set into this mode by setting CommandLocal. In the first case, the adapter extracts commands from a PROM that are intended to start paper motion and printing. Two switches (Switch3 and Switch4) govern the selection of one of four local command sequences that is extracted from the PROM. In both local cases, the adapter will generate "graph paper" video signals governed by the video gate counter (VideoGate) and the line sync delay register (LineSyncDelay). In order to see graph paper cover the page, VideoGate and LineSyncDelay must be set in such a way that they are counting as the beam passes all spots on the page.

To aid debugging the adapter itself, the TestMode bit may be set. This permits the crucial printer and ROS timing signals to be generated in the adapter rather than in the engine. If TestMode is set, PageSync is taken from the complement of the control bit TestPageSync’, and line sync (analogous to start-of-scan) is generated by the motor control circuitry: on the M adapter, it will be on for (15/16) * (4096-MotorSpeed) / crystalClock seconds and off for (1/16) * (4096-MotorSpeed) / crystalClock seconds; on the T adapter, it will be a signal on for 4 * (4096-MotorSpeed) / crystalClock seconds and off for the same amount of time. The "on" portions of these signals simulate scan-lines of the corresponding durations.

The BeamEnable status bit means that the doors to the ROS housing and/or printing engine are closed, and the interlocks have engaged.

To force the laser beam on, and consequently to allow the servos to settle down, either CommandBeamOn or StatusBeamOn may be set. CommandBeamOn may be set by the EIP, and StatusBeamOn can be set with a switch in the ROS housing (M adapter).

There are four switches on the adapter module that can be used to alter the operation slightly. The VideoPolarity switch will invert the sense of the binary signal sent to the beam modulator. SelectLeadEdge is a switch that selects either leading or trailing edges of the SOS and EOS signals for careful timing purposes (different ROS boxes operate differently).

Adapter errors. The adapter keeps track of various kinds of errors that may occur during its operation, and reports some status bits. If the adapter detects errors on the line that delivers commands to the adapter, it sets LineNoise or CompareError and ignores the command. If the EIP fails to provide video data fast enough, the adapter sets BufferUnderflow (this condition is reset by the Buffer reset command). The PacketsOK condition is set by the Buffer reset command, and cleared whenever an improperly-formatted video data packet is received from the EIP.

3. The Dover Printer

The Dover printer is a Xerox 7000 copier, modified to substitute a ROS module for the optics and to incorporate an engine controller that permits the printing operations to be controlled adequately by the adapter. This section describes the standard Dover engine, which operates at a paper speed of 10 inches/second. Dover can be "extended" in an experimental setting to run at 5 inches/second. The timing for the extended Dover is very different than the timing described here.

3.1 Engine Parameters

Several engine parameters were mentioned in the adapter section. The values for Dover are:

p10 inches/second
f32 facet polygon
r24 clocks/revolution
d.90 scan-line duty cycle
h12.5 inches

Typical settings in the T adapter for S=B=350 bits/inch are:

BitRate=17 * 106
MotorRPS=109.38
MotorSpeed=1707
MotorScale=7
BitClock=3002
BitScale=7
LineSyncDelay=4046 (3008 for entire line for graph paper)
PageSyncDelay=3971 (3596 on Dover II)
VideoGate=3352

3.2 Engine timing

The engine timing for Dover is somewhat intricate, as there is a substantial "pipeline" effect in the paper path. The philosophy used in designing the engine control electronics has been to make them simple, and to require the EIP program controlling the engine responsible for sorting out most of the timing details.

There is only one signal used to instruct the Dover engine: a PrintRequest signal that is generated by a 0-to-1 transition of the low order bit of ExternalCommand1. Thus two successive adapter commands (first 60001b, and then 60000b) are normally used to cause the PrintRequest signal. The PrintRequest signal is used by Dover to feed sheets; be warned, however, that initiating and terminating a printing sequence are both a bit tricky, and require careful thinking (more on this below).

Dover generates only one timing signal of interest: CS-5, which is transmitted to the adapter as the PageSync signal. All timing information relevant for paper-path motion is derived from this signal. For purposes of discussion, it is helpful to "number" each of the CS-5 pulses generated by the engine, starting with CS-5(0), the first to be generated as the machine cycles up.

We shall describe the operation of Dover by describing the various sequences involved: (a) a cold start assuming the motor is presently off (PrintMode is off); (b) the "inner loop," in which paper is happily flowing through the engine, and page after page is being printed; (c) the runout shut-down sequence; and (d) the malfunction shut-down sequence.

Inner loop. We shall begin by describing the inner loop, as it is the simplest sequence. Refer to Figure 3-1 for an illustration of the timing. Let us assume that CS-5(n) has just occurred. Approximately 250 ms. later, the adapter should begin sending video to the ROS that will correspond to the leading edge (left-hand edge) of the paper. This time will vary a little from machine to machine, and can be controlled with the help of the PageSyncDelay register in the adapter. Imaging the page persists for about 850 ms. Approximately 896 ms. after CS-5(n), the Count-H status signal is generated and persists until the next CS-5 (Emperically, Count-H is on for only about 20ms. in older adapters; it is much wider in Dover II adapters. Special provisions in the standard microcode provide help in detecting this signal reliably.) This signal indicates that paper was successfully fed to hold the image for the page that is being imaged on the drum. If Count-H does not appear at the proper time, it is likely that some malfunction has, or is about to, occur. Within 990 ms. after CS-5(n), it is necessary to issue a new PrintRequest (i.e., to send the adapter a "set External Command 1" command) if another sheet is to be fed (i.e., if you desire to keep printing at high speed).

Cold start. In order to initiate printing, the EIP issues a PrintRequest (again, by issuing the "set External Command 1" command to the adapter). PrintMode should come on, verifying that power has been applied to the main motor. About 250 ms. after the print request, CS-5(0) is generated. This first CS-5 identifies a machine cycle that will not result in an output page: if you were to interpret CS-5(0) in the fashion described above for the inner loop, the first image you delivered would not be blessed with a sheet of paper to receive it. However, if you issue a second PrintRequest within 990 ms. of CS-5(0), the machine will cycle again, and generate CS-5(1). This CS-5 does in fact correspond to a sheet of paper -- now you may enter the inner loop.

A convenient way to think of the cold start sequence is to start the inner loop with CS-5(0), with two additional features on the first page imaged: (1) it will not be transferred to paper, and should therefore be "white" (in order to insure the bit clock servo is running properly), and (2) the Count-H signal will not be generated, because no sheet of paper was actually fed.

Runout shut-down. Dover begins shut-down whenever it fails to receive a PrintRequest in time (i.e., within 990 ms. of a CS-5). The machine must continue to operate for some time, however, in order to allow the last sheet of paper to be fused and transported to the output hopper. There will be 7 gratutitous CS-5 pulses generated after the last CS-5 that was produced by a PrintRequest. At the end of this sequence, PrintMode is turned off, indicating that paper path motion has stopped. In order to re-start the machine, a cold-start sequence is required.

If you wish to resume printing before the 7th CS-5 has passed, you may resume issuing PrintRequests, just as if you were in the inner loop (i.e., the first CS-5 after your PrintRequest will be blessed with a corresponding sheet of paper).

Malfunction shut-down. When a malfunction is detected, the Dover printer shuts down immediately, and does not wait for paper to be transported out of the machine. An appropriate malfunction status bit will be turned on (see next section), and the machine will halt (PrintMode goes away; no more CS-5’s will happen). After an operator has corrected the problem, the machine must be restarted with the cold-start sequence.

3.3 Engine status indications

Dover may report up to 32 bits of status to the EIP via the adapter. Most of these bits are unused. The table below gives the name of each status bit and a short description of its purpose. The various malfunction indications are followed by a quoted string in italics; this is the recommended operator message for the condition (adherence to standard messages simplifies the job of the trouble-shooter).

WordBitSignal

83Count-H. This signal is raised if a sheet has been successfully fed to receive the image for the page being imaged. Count-H comes on 896 ms. after CS-5 and persists until the next CS-5.

85PTDisorder. This signal is active when the paper tray is not in the up position or when the paper tray cover is open. It persists until the condition is corrected. This is the "or" of (not LS4) and (not LS24&LS31). "Paper tray open."

88* LS4. This signal is active when there is adequate paper in the paper tray. A zero value will also assert PTDisorder.

810LS27. This signal is active when progress from the A transport to the register stop module is not normal. It persists until the paper is cleared. "Jam--paper feed."

811* LaserOn. This signal is active when the laser power supply is on, and the beam is available for use. "Laser is off." (Applies when the status bit is not present.)

812* LS22. Malfunction Reset. Left as an exercise to the reader.

813ReadyTemp. This signal is active when the fuser temperature is above 285 degrees F. This corresponds to the minimum temperature needed to fuse the toner to the paper. "Fuser not warm." (Applies when the status bit is not present.)

814LostPower. This signal is active when machine power is turned off when PrintMode was active (i.e., the main drive motor was energized). It persists until the paper is cleared. "Lost engine power."

815* ModeCont. This signal is active if the machine is set to run in its "extended", or half-speed, configuration.

91PhotoCellOut. This signal is active when a sheet of paper has not been knocked off the drum during machine operation. It persists until the paper is cleared. "Jam--paper on drum."

92PreSeq. This signal is active if a malfunction occurs before the first page is imaged (i.e., during the power-up sequence). "Jam--startup sequence."

94* LS9. Two pieces of paper were fed. "Jam--two sheets fed."

95ACMonitor. This signal is active when the machine is powered up. It is possible to have ReadyTemp-H active even though the ACMonitor-H is not. "Engine not powered up." (Applies when status bit is not present.)

96LS38. This signal is active when a sheet of paper is jammed on the fuser roll. "Jam--paper on fuser roll."

98* LS1. B Transport Jam. "Jam--B Transport."

99Malfunction. This is a general-purpose signal that is the "or" of all the possible error indications given above (PTDisorder, LS27, LS22, LostPower, PhotoCellOut, PreSeq, LS38, LS1, LS3).

910LS3. This signal is active when a sheet is not knocked off the drum and PhotoCellOut-H does not catch it. It persists until the paper is cleared. "Jam--paper on drum."

913* LS24&LS31. Paper tray is up and sensing bar is in place. Normally active. A zero value will also assert PT-Disorder.

* Meaningful for Dover II adapters only.

4. Performance

This section gives preliminary results on the performance of Orbit in actual printing runs. The basic test is to place as many characters of a given size on a page as possible before Orbit "gets behind." Orbit will get behind when the demands of composing video for a complex page exceed the speed capacities of the Alto and Orbit.

For these tests, Orbit is attached to a Dover printer running at 10 inches per second, 350 scan-lines per inch, 350 bits per inch. The Alto II driving Orbit is perfectly standard--the "disk" it uses is a Diablo Model 31. The fonts used are all versions of Helvetica, scan-converted from spline representations. The tests reported here use the "standard" Orbit microcode, and do not resort to trickery of any kind. Orbit is flexible enough to do quite a bit more than is reported here.

Bandwidth Capacity

CharacterNominalWith diskWithout disk
point sizechars/page

Portrait:
6>11632*>11632*>11632*
88748>1026011137
105460>75607980
123618>6300<6365
142622>45034731

Landscape:
6>14000*>14000*>14000*
88576>11008<11124
105508>82148724<9030
123735>5058>6516
142652>4900>5035

Explanation. The nominal number of characters per page is the number of characters of the given size that fit comfortably (without squeezing or overprinting) on a page. These numbers compare reasonably well with typical pages printed on EARS. The third and fourth columns give Orbit’s measured capacity. The third column is measured with disk activity present (the assumption is that while printing a page of a given complexity, you must be reading from the disk into another buffer a description of the next page, so that printing at the given capacity can continue uninterrupted). The fourth column is measured with disk activity absent. Note that absence of disk activity increases capacity only slightly. (Starred items exceeded character sort size in my test program.)

Storage capacity

CharacterFont storage
point sizein words/character

Portrait:
624.3
839.8
1059.1
1283.7
14111.

Landscape:
623.9
839.4
1058.6
1282.9
14111.

The table above gives storage requirements for a single character, including the necessary index table. Note that with Orbit, it is straightforward to economize on font storage by including only those individual characters known to be used on the page.

Storage requirements for a "page description" (i.e., information about which characters are to appear where) are:

2 words/character +
4 words/rule (horizontal and vertical lines) +
st/8

where st is the total number of scan-lines on the (active) part of the page.

Rule of thumb

There is a model (the details of which I will avoid stating here) that can be used to estimate the numbers given above. Let r be the resolution of the ROS in bits/inch. Let s be the point-size of characters. Let p be 1.0 for fixed-pitch fonts and .6 for proportionally-spaced fonts. Let t be the total imaging time in seconds (.85 for Dover).

The number of font storage words per character is roughly 3 + 7.2*10-6 p (rs)2. The maximum capacity of Orbit in characters per page is roughly 2.1*106 t/(2.1*10-5 p (rs)2 + 2.3*10-2 p rs - 6).

5. Miscellaneous

A pattern generator for gray (shaded) areas. A simple algorithm will generate acceptable gray patches on most printers. The scheme, devised by Mike Wilmer, is used to compute an 8-by-8 bit pattern that can be replicated laterally to produce the shade (the INK memory can help with this). If you want a darkness D, where 0 corresponds to white, and 63 to black, a bit of the pattern should be 1 (black) if D is greater than the entry in the following 8-by-8 table:

44 39 31 17 09 25 37 52
20 26 33 41 49 35 28 12
00 10 50 57 61 46 22 02
06 18 42 58 62 54 14 04
08 24 36 53 45 38 30 16
48 34 29 13 21 27 32 40
60 47 23 03 01 11 51 56
62 55 15 05 07 19 43 59

References

Severo Ornstein, "Orbit General Description," PARC/CSL Memo.
Orbit Logic Drawings
Orbit Standard Microcode, saved on <DOVER>OrbitMc.Mu

"ROS Adapter Functional Description," saved on RosAdFuncDesc.Ears.
MECL version logic drawings saved on RosAdFiles.dm.