DPS 1200 series

Template:Infobox CPU architectureThe DPS 1200 series was a family of computer systems and compatible peripherals that the Themiclesian company Data Processing Systems announced in 1964 and released in 1965. It was conceptually similar to its competitor the 630 series released by OS computer developer and manufacturer UBMC in the previous year. The DPS 1200 is noted as the platforms on which several unconventional products appeared. /1200 was a market success in Themiclesia, due both to the compatibility of the processors and peripherals and the provision of language-specific adaptations for non-Tyrannian characters. /1200 is regarded as a third-generation computer given the presence of primitive integrated circuitry, as opposed to the discrete transistor logic that characterized its predecessors.

Key features

Conceptual origin

/1200 was announced one year after the debut of UBMC's 630 in the Organized States; most commentators therefore consider the /1200 to be, conceptually, an unambiguous imitation. However, there was no effort on UBMC's part to prosecute DPS for infringement on patents and commercial secrets, suggesting that the two have reached some sort of secret arrangment. Technical analyses of these systems reveal that the two systems operated rather differently, that such a suit was unlikely to succeed; additionally, UBMC's control over the OS computer market, then largest in the world, drew suspicion from government authorities of anti-competitive or collusory practices. A notable fact regarding the /1200 was that its OS distributors did not price it any more competitively than UBMC's products, and sales in the OS were minimal compared to its distribution in Eastern Hemithea.

Firmware use

Like the 630, /1200 had a unified instruction set implemented in various different ways across a range of processors (which the DPS called Binary Logic Unit or BLU). In general, the more powerful the processor, the more instructions were implemented in hardware (i.e. physical circuitry), and conversely, the smaller ones used firmware to translate complex instructions into simpler ones which, in parallel or sequence, produced the same results as the original, complex one. The drawback of using firmware is that it would require multiple machine instructions (hence more processor cycles) to accomplish what a more powerful processor could accomplish in a single cycle or fewer cycles.

Expanded word size

/1200 is one of few computer systems to support a 72-bit word size. This figures comes from the duplication of two 36-bit words, common on UBMC's systems earlier in the decade, though that company switched to 32-bit for the 630. It seems originally there were plans to make /1200 at least partly compatible with programs that ran on UBMC's older systems, which were present in Themiclesia in considerable numbers, though such features were never announced in official literature. A 72-bit word is called a "double word", further supporting the hypothesis that it was meant to run UBMC's 36-bit instructions, but it did have an inventory of 36-bit instructions of its own.

Open platform

DPS published the full instruction set of the /1200 the same year it released it, contrasting UBMC's relatively closed approach of only allowing software engineers to code for its hardware, or at least the parts that were sold with the system anyway. DPS believed the only way it could compete with UBMC's massive market presence was through such an open-ended approach. DPS also developed a much-improved programming language with better mnemonics and a faster assembler. Several years later, to extend the /1200's life, DPS also developed an object-oriented language now conventionally called B (or affectionately 🅱 in some circles). The rationale for this name choice was never provided.

Hardware

Processors

The common instruction set of /1200 is available on all processors.

Model	Introduced	Microcode	Performance (MIPS)	Max. Memory capacity (kW)	Notes
01	Mar. 1965	Yes	0.04	9
02	Mar. 1965	Yes	0.08	9
03	Mar. 1965	Partly	0.3	72
04	Mar. 1965	Customizations	1.03	72
05	Oct. 1967	Partly	0.83	72
06	Oct. 1967	Partly	0.52	36
07	Oct. 1967	Customizations	8.6	1,000	Contains "standard" custom instructions for complex mathematical operations
08	Jun. 1968	Partly	1.75	500
09	Jun. 1968	Customizations	4.11	500
10	Nov. 1969	Customizations	1.73	500
11	Dec. 1969	Partly	8.22	1,040	Memory fetch two cycles
12	Oct. 1970	Customizations	12.54	640
13	Feb. 1972	Customizations	6.54	640
14	Sep. 1973	Customizations	1.38	243
15	Sep. 1973	Customizations	5.54	640

Storage

Magnetic core memory was available as an option, though into the 1970s solid-state memory was also available; the latter option was specific to each program, and a compatible replacement for core was not developed in time before the /1200's successor appeared. Typical for /1200 operation, only program code was stored in memory; most data was accessed from punched cards, magnetic tape, and, in select cases, hard disc drives. Since the /1200 had a word size of 72 bits, memory capacity is usually quoted in words, instead of bytes. Each system requires at least 4 kW of main memory to function, and for smaller installations running sequential jobs this was often sufficient; however, when multiple channels are present, larger memory size speeds up the system considerably. DPS recommended installing at least 36 kW of main memory for a time-sharing system.

I/O

Like most computers of its day and role, /1200 accepted input from punched cards (via the /121 Card Reader), several models of tape drives, hard disc drives, and terminal input. Control panel input, save during debugging or serious repairs, was obsolete by this point. The computer also delivered output via punched cards (/131 Card Punch), tape drives, hard disc drives, terminal output, and printer. Similarly, the states of each register after the last instruction are visible on the control panel; this was especially useful for debugging, since the state of the system would be visible at the very point the final instruction that caused the system crash.

Instruction architecture

Instructions on the /1200 were register-to-register, register-to-memory and vice versa, and memory-to-memory. /1200 could, theoretically, process instructions that have up to four operands; however, such instructions did not exist in the common instruction set. As triple-operand instructions already consumed a large amount of space to implement in hardware, where quadruple-operand instructions appear, they were always realized through microcode. Normal instructions could have lengths of full (72-bit), half (36-bit), or quarter (18-bit) word; extended instructions could have up to 126 bits, though restrictions exist on the sort of operations permitted in such over-long instructions (mostly to ensure the processor correctly interprets all parameters of the instruction). Each category had different sets of instructions that operated on different operands, such as immediate fields (in which a number is specified explicitly in the instruction), registers, and memory locations. An instruction could also send direct commands to other hardware components without specifying data residing in its storage. As is typical on a CISC machine, /1200 supports a large number of instructions, making its programming comparatively intuitive and "vivid" as recounted by Ms. R. Davone of Kerenevoi.

The first two bits specified instruction length. The next six bits specified the opcode. The remainder depends on the length of the instruction selected. The machine could process multiple instructions at once, though this is less of an innovation, being simply duplicate circuitry in two different parts of the instruction space. Only the most common instructions received this treatment, as otherwise the amount of logic would grow uncontrollably, and frequent conflicts would result from simultaneous reads and writes to the same memory address(es). If an extended instruction is specified, the machine simultaneously processes the first half and sends for the second half in memory; once the first part has been processed, the second part arrives in tandem as the first half is stored to register/memory, and it is processed immediately, without wasting time in between.

Software

Operating system

/1200 came with two operating systems, one intended for batch processing and another for time-sharing. Despite sharing the name "time-sharing" with a similar program from UBMC, their operations are radically different. The first system creates a list of jobs in main memory with designated start- and end-points where the machine should seek out the new program to be loaded and the data to be processed; for this, there is a block in memory (usually the final 32 words) used for storing such logs. The operator accesses this log via a console or, in rare cases, the control panel. The batch processing system was not meant for output to terminal, though third-party software were soon written to enable this function. The second system is more complex and required additional hardware. /1200 can maintain connectivity with up to 16 channels at one time, and correspondingly each controller has an internal clock ​¹⁄₁₆ the speed of that of the processor. These controllers, other than a memory controller accessing optional banks of main storage and an I/O controller accessing unit-record equipment, could communicate with video terminals for output. The terminals meant to be used in conjunction with /1200 are dumb terminals; except very simple tasks like generating Tyrannian characters and checking for parity errors, all processing on data entered through the terminal takes place in the processor.

Applications

There is a wide variety of applications written by third-parties for the /1200, which was quite popular in Themiclesia. DPS did not develop an extensive library for this system, though they did publish a journal that advertised software developed by third parties. Since the journal saw extensive subscription, any exorbitant pricing on software was quickly rectified by substitutes written by other developers, leading to one of the earliest competitive software markets in Themiclesia. Typical titles dealt with financial accounts, statistical analysis, stock inventories, record keeping, and scientific simulation.

Emulators

/1200 was able to emulate a range of earlier machines, from a variety of manufacturers. Most of these were accomplished through microcode and software, but a collection of hardware emulators exist, all of which were provided by DPS. While development of third-party hardware was not forbidden, the developmental costs often were considerable, and few such products emerged on the open market.

Peripherals

/1510 GG

Main article: Graphics Generator

GG is a dynamic, graphics-manipulating computer system that was organized as a variation of the /1200 line. It included circuitry dedicated to generate and manipulate two-dimensional graphics on an attached bi-stable CRT display with 512×512 resolution. The system could be programmed to move any number of shapes on screen, though it could not "remember" where each shape was; hence, when one wished to generate a circle and move it across the screen, one programs the system to generate a circle around a centre point, move the centre point, generate a circle again, and so forth. Because the display was bi-stable, it is necessary to erase the old image before the new one was drawn, so that a clean image is created by persistance of motion. This is accomplished by flipping a control bit that alters the electron beam so as to disrupt the excited phosphor and return it to the ground (unlit) state.

While this eliminated the need for an impractically-large main storage to hold the screen information, it also made programming it rather finicky. Specialists working on it developed the practice of defining all graphics in terms of geometric shapes with a centre point; this way, the position of the on-screen object could be stored with only a quarter-word, as a cartesian co-ordinate of the centre point and the parameters used to generate its borders, in main memory (which was often only 8 kW). Given this information, programmers could check the anticipated x- and y co-ordinates for identity with another object by using simple compare instructions, therefore detecting collision. The development of collision detection was crucial to the rise of video games, and for this reason many experts believe the GG was the first system to be capable of video games.

/1292 BEANS

Main article: Basic Electromagnetic Amplitude-modulated Nexual System (BEANS)

BEANS was an arrangement of a /1200 system that was customized for military use. Due to lack of consultation with the Signals Corps (who were to receive its use), BEANS proved far too fragile, heavy, sensitive, and difficult to program and use on the field. It was distributed to the Themiclesian Army in 1968 and withdrawn in 1976, and rights to BEANS were released by DPS to purchasers in Dayashina, New Tyran, Kerenevoi, and the Organized States, where they saw further elaboration.

/1360 OOF

Main article: Optimized Orthography Facility

OOF was DPS' solution to processing text on what has hitherto been a Tyrannian-only platform. This option stored 8,192 Shinasthana characters as 7×8 rasters and enabled their display on the analog video terminals. It also came with its own printer, which was a peculiar device that "printed" Shinasthana text not unlike a dot matrix printer, except it printed the top row of dots of every character in the same row. The memory structure of OOF made such an arrangement sensible.

Impact

Perpetuation of spaghetti code

Some programmers believe that the ability to add custom instructions by pre-defining them in microcode has perpetuated spaghetti code, characterized by a linear sequence of instructions that do not form independent groups specializing in discrete functions. They also believe that the extensive array of compare-and-branch instructions, offered natively by /1200, prevented Themiclesian programmers from adopting structural programming and high-level languages, instead abiding with unstructured programming and assembly language. Programming this way can save memory space by using one piece of code in multiple program flows; they would be separated by arbitrarily assigned characteristics (which persists despite the operation) and branch instructions that recognizes these characteristic and thereby restore the independence of these flows. While economical on memory, other programmers often find it challenging to follow a specific flow when it merges with other flows, and only the original programmer would intuitively know how such flows become independent again. To others, the index appears to bounce randomly between instructions, hence the comparison to entangled spaghetti. These practices have been critized as anti-competitve, since foreign programmers are essentially unable to enter the Themiclesian market.

See also

• Basic Electromagnetic Amplitude-modulated Nexual System (BEANS)
• Optimized Orthography Facility