GRASS (programming language): Difference between revisions

Revision as of 22:16, 20 February 2024

Latest revision as of 00:31, 15 August 2025

(5 intermediate revisions by 3 users not shown)

Line 2:

'''GRASS''' (''GRAphics Symbiosis System'') is a [[programming language]] created to script [[2D computer graphics|2D]] [[vector graphics]] animations. GRASS was similar to [[BASIC]] in syntax, but added numerous instructions for specifying 2D object animation, including scaling, translation and rotation over time. These functions were directly supported by the [[Vector General 3D]] [[graphics terminal]] GRASS was written for. It quickly became a hit with the artistic community who were experimenting with the new medium of [[computer graphics]], and is most famous for its use by [[Larry Cuba]] to create the original "attacking the [[Death Star]] will not be easy" animation in ''[[Star Wars (film)|Star Wars]]'' (1977).

As part of a later partnership with [[Midway Games]], the language was ported to the Midway's [[Zilog Z80|Z80]]-based Z Box. This machine used [[raster graphic]]s and a form of [[Sprite (computer graphics)|sprites]], which required extensive changes to support, along with animating color changes. This version was known as '''ZgrassZGRASS'''.

==History==

Line 11:

After graduation, DeFanti moved to the [[University of Illinois at Chicago|University of Illinois, Chicago Circle]]. There he joined up with [[Dan Sandin]] and together they formed the ''Circle Graphics Habitat'' (today known as the ''[[Electronic Visualization Laboratory]]'', or EVL). Sandin had joined the university in 1971 and built the [[Sandin Image Processor]], or IP. The IP was an [[analog computer]] which took two video inputs, mixed them, colored the results, and then re-created TV output. He described it as the video version of a [[Moog synthesizer]].{{sfn|DeFanti|1980}}

DeFanti added the existing GRASS system as the input to the IP, creating the '''GRASS/Image Processor''', which was used throughout the mid-1970s. In order to make the system more useful, DeFanti and Sandin added all sorts of "one-off" commands to the existing GRASS system, but these changes also made the language considerably more idiosyncratic. In 1977 another member of the Habitat, Nola Donato, re-designed many of GRASS's control structures into more general forms, resulting in the considerably cleaner '''GRASS3'''.{{sfn|DeFanti|1980}}

[[Larry Cuba]]'s ''Star Wars'' work is based on semi-automated filming of a GRASS system running on a [[Vector General 3D]] terminal. The VG3D had internal hardware that performed basic transformations - scaling, rotation, etc. - in realtime without interacting with the computer. It is only during the times when new scenery is being presented that the much slower communications with the GRASS language takes place. This can be seen in the sequence, as the initial sections of the film show the [[Death Star]] being rotated and scaled very rapidly, while the later sections simulating flight down the trench requires new scenery to be paged in from GRASS "trees". These can be seen appearing in groups.

===ZgrassZGRASS and UV-1===

In 1977, DeFanti was introduced to Jeff Frederiksen, a chip designer working at [[Dave Nutting Associates]]. Nutting had been contracted by Midway, the videogame division of Bally, to create a standardized [[videoVideo display unitcontroller|graphics driver chip]]. They intended to use it in most of their future arcade games, as well as a [[video game console]] they were working on which would later turn into the [[Astrocade]]. Midway was quite interested in seeing the GRASS language running on their system, and contracted DeFanti to port it to the platform. A number of people at the Habitat, as well as some from Nutting, worked on the project, which they referred to as the '''Z Box'''. GRASS3 running on it became '''ZgrassZGRASS'''.{{sfn|DeFanti|1980}}

The Z-Box was a [[raster graphics]] machine, unlike the original GRASS systems, so while most of the GRASS3 style was maintained in ZgrassZGRASS, it added a number of commands dedicated to raster images. This included an extensive set of [[bit blit|bit block transfer]] commands in order to simulate [[sprite (computer science)|sprite]]s, something the hardware didn't include.{{sfn|DeFanti|1980}} The work would never be released by Midway, but the Circle would produce machines based on it as the [[Datamax UV-1]].

===GRASS RT/1===

Line 24:

== Description ==

:''This description is based on the original Bally manuals as well as the ACM description.''{{sfn|DeFanti|Fenton|Donato|1978}}

Zgrass was based on a standard set of BASIC commands and used most of its syntax. Where Zgrass differed from BASIC was that all commands were in fact [[function (programming)|function]]s and returned values, similar to the [[C (programming language)|C programming language]]. If there was no obvious return value it was expected that a function would return 1 if it succeeded, and 0 if it failed. For instance, the command <code>PRINT PRINT 10</code> would be illegal in BASIC, but in Zgrass this would print <code>10 1</code>, the 1 being the value returned by second <code>PRINT</code>, meaning "I successfully output the string '10'".

Line 43:

Zgrass also included a series of commands that "covered" CP/M, which allowed the disk to be accessed without exiting to the command prompt. You could easily save out macros to named files, and load them in the same way, allowing you to construct programs by loading up various macros from the disk into one large program. The commands also automatically made a backup copy of every save. Similar features were supported for [[Compact Cassette (data)|Compact Cassette]] storage, but oddly the syntax was not parallel: disk commands were D-something, like {{code|DPUT}}, but tape commands were not T-something, like {{code|TPUT}}, but rather something-TAPE, like {{code|PUTTAPE}}.

With programs constructed from randomlyarbitrarily selected modules, Zgrass needed to have better control over its variables than BASIC. In BASIC all variables are "global", so if two subroutines both use the variable {{code|I}}, which is very commonly used as a loop index variable, then they could set each other's values which leads to hard-to-debug problems. Under Zgrass a programmer loading up two modules could easily find that both used {{code|I}} as a loop counter, which could cause problems. To address this issue, Zgrass considered variables named with [[lowercase]] letters to be local only to that macro, so {{code|I}} and {{code|i}} were different variables, global and local respectively. Oddly, the examples provided with the language do not make widespread use of this feature, potentially confusing new programmers who might not be aware the feature exists.

==Example==