GRASS (programming language): Difference between revisions

Revision as of 23:13, 28 March 2003

Latest revision as of 00:31, 15 August 2025

(116 intermediate revisions by 62 users not shown)

Line 1:

{{about|the programming language|the GIS system|Grass GIS}}

'''GRASS''' (''GRAphics Symbiosis System'') wasis a [[programming language]] created to script visual[[2D animations incomputer graphics|2D]] [[vector graphics]] animations. GRASS was similar to the [[BASIC programming language]] in syntax, but added numerous instructions for specifying 2D object animation, including scaling, translation, rotation and color changesrotation 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 will remainis most famous for its use by [[Larry Cuba]] to create the original "attacking the death[[Death starStar]] 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 '''ZGRASS'''.

=== History ===

=== History ===

The original version of GRASS was developed by Tom DeFanti for his 1974 [[Ohio State University]] Ph.D. thesis. It was developed on a [[PDP-11]]/45 driving a Vector General 3DR display, and as the name implies, this was a purely [[vector graphics]] machine. GRASS included a number of vector-drawing commands, and could organize collections of them into a hierarchy, applying the various animation effects to whole "trees" of the image at once. It was this version that was used for the Star Wars animation, if you re-watch this portion of the film you can see whole trees popping into the image at various times. After graduation he moved to the [[University of Illinois]], Chicago Circle.

===GRASS===

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 set about building what he thought of as the video version of a [[Moog]], known as 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.

The original version of GRASS was developed by [[Tom DeFanti]] for his 1974 [[Ohio State University]] Ph.D. thesis.{{sfn|DeFanti|1980}} It was developed on a [[PDP-11]]/45 driving a [[Vector General 3D|Vector General 3DR]] display, and.{{sfn|DeFanti|1980}} asAs the name implies, this was a purely [[vector graphics]] machine. GRASS included a number of vector-drawing commands, and could organize collections of them into a hierarchy, applying the various animation effects to whole "trees" of the image at once. It(stored wasin this version that was used for the Star Wars animation, if you re-watch this portion of the film you can see whole trees popping into the image at various times. After graduation he moved to the [[University of Illinois]], Chicago Circlearrays).{{sfn|DeFanti|1980}}

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 set about building what he thought of as the video version of a [[Moog]], known asbuilt 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.

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}}

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 graphics driver chip. They intended to use it in most of their future arcade games, as well as a [[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 '''Zgrass'''. The work would never be released by Midway, but the Circle would produce machines based on it as the [[Datamax UV-1]].

[[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.

The Z-Box was a [[raster graphics]] machine, unlike the original GRASS systems, so while most of the GRASS3 style was maintained in Zgrass, it added a number of commands dedicated to raster images. This included an extensive set of [[blitter]] commands in order to simulate [[sprite]]s, something the hardware didn't include.

===ZGRASS and UV-1===

The last version of GRASS was '''RT/1''', a port of GRASS to other platforms that divorced the language from the display model and allowed it to be ported to other platforms. Versions existed for [[DOS]], [[Windows]], [[SGI]] platform using [[OpenGL]], [[HP-UX]], [[AIX]], [[Apple Macintosh|Macintosh]] and [[Amiga]]. The language remains similar to the earlier versions, so the reason for the change of name is unclear.

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 [[Video display controller|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'''. The work would never be released by Midway, but the Circle would produce machines based on it as the [[Datamax UV-1]].{{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 [[blitterbit 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]].

It is perhaps the introduction of the fully graphical systems like [[Macromind Director]] that made a language like Zgrass fade away.

===GRASS Description RT/1===

The last version of GRASS was '''RT/1''', a port of GRASS to other platforms that divorced the language from the display model and allowed it to be ported to other platforms. Versions existed for [[MS-DOS]], [[Microsoft Windows]], [[Silicon Graphics|SGI]] platform using [[OpenGL]], [[HP-UX]], [[IBM AIX|AIX]], [[AppleMac Macintosh(computer)|Macintosh]] and [[Amiga]]. The language remains similar to the earlier versions, so the reason for the change of name is unclear.

== Description ==

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]]. 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> (1 means "success").

:''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>, (1meaning means"I successfully output the string '10'"success").

Programs in Zgrass were referred to as ''"macros''", and stored as strings. Both of these oddities were deliberate, as Zgrass allowed any string to become a program. For instance, <code>MYBOX="BOX 0,0,100,100,2"</code> defines a string (no need for a $ on the variable as in [[Microsoft BASIC]]s) containing a snippet of Zgrass code. Simply typing <{{code>|MYBOX</code>}} from that point on would run the command(s) inside. This feature can be used in place of the more traditional <code>GOSUB</code> command from BASIC, but has the added advantage of having a well -defined name as opposed to an opaque line number. In addition, the command remains in the form of a string, in memory and can be manipulated at runtime with standard string operations.

Most BASIC [[interpreter (computer softwarecomputing)|interpreters]] of the era converted the input text into a ''[[Lexical analysis|tokenized]]'' version in which each of the commands was replaced by a single number (typically one [[byte]] long). This made the program run faster because it didn't have to continually decode the commands from the strings every time. Zgrass's use of string-based macros made this difficult, so they didn't bother with tokenization. Instead, they included a [[compiler]] which could be used on any particular macro, speeding it up many times. Programs would often consist of a mix of compiled and uncompiled macros.

Line numbers were optional in Zgrass, and typically only appeared on lines that were the target of a <code>GOTO</code>. Most BASIC interpreters required line numbers for every line of code, but this was due to their use in the "line editor"&ndash;if you needed to edit ''that''a particular line, the only way to refer to it was by number. Zgrass used a more advanced full-screen editor that eliminated this need (as was the case for [[True BASIC]]). Zgrass allowed any string to act as a "line number", <{{code>|GOTO 10</code>}} and <{{code>|GOTO MARKER</code>}} were both valid. Zgrass included nameless branches, using the <code>SKIP</code> instruction, which would move forward or back a given number of lines.

Zgrass also included nameless branches, using the {{code|SKIP}} instruction, which would move forward or back a given number of lines. This is important in Zgrass as the line numbers were optional and different macros might make use of the same labels. For instance, some variation on {{code|LOOPSTART}} is likely to be found in many bits of code, and thus {{code|GOTO LOOPSTART}} might result in a name clash. Using {{code|SKIP}} avoided this possibility.

In keeping with its original purpose as a graphics language, Zgrass included numerous commands for simple drawing. The system deliberately used the display from the Astrocade hardware as its own coordinate system, but the Astrocade could display only 1/2 the resolution. To avoid potential mapping problems, the coordinate space's zero point was placed in the center of the screen. -160 to 160 were valid X locations, and -101 to 101 valid Y locations. For use on the Astrocade you used the positive locations only, whereas on the UV-1 the entire space was available.

In keeping with its original purpose as a graphics language, Zgrass included numerous commands for simple drawing. TheZgrass's coordinate system deliberatelyhad usedone thepoint displayfor fromeach thepixel Astrocadein hardwarethe ashigh-resolution itsmode ownof coordinateNutting's systemgraphics chip, butgiving thea 320×202 grid. The Astrocade, couldby displaydesign, could only 1/2use thethat chip's low-resolution mode, a 160×101 display. To avoid potential mapping problems, the coordinate space's zero point was placed in the center of the screen. -&minus;160 to 160 were valid X locations, and -101 to 101 valid Y locations. For use on the Astrocade you used the positive locations only, whereas on the UV-1 the entire space was available.

Zgrass added a fairly complete set of array functions, as arrays are widely used in graphics. This included the ability to "capture" parts of the display into an array as a [[bitmap]], which could then be manipulated as any other graphic item. This allowed Zgrass to include [[sprite]]-like functionality in the language, as the Astrocade hardware did not include this feature. Another feature the Astrocade did not include was the ability to process arrays with any reasonable speed, so the Z-Box included the Zilog supplied [[FPU]] for added performance.

Zgrass added a fairly complete set of array functions, as arrays are widely used in graphics. This included the ability to "capture" parts of the display into an array as a [[bitmap]], which could then be manipulated as any other graphic item. This allowed Zgrass to include [[sprite]]-like functionality in the language, assomething the AstrocadeNutting hardware did not directly include this feature. Another feature the Astrocade did not include was the ability to process arrays with any reasonable speed, so the ZUV-Box1 included thea Zilog supplied [[floating-point unit|FPU]] for added performance.

Zgrass included three priorities (called ''levels'') and allowed macros to be run normally, or in ''foreground'' or ''background'' levels. This added a simple form of [[multitasking]] which was tremendously useful in a animation-oriented language. Game authors could place joystick-reading routines in a macro set to run in the background, and then the joystick would be read automatically whenever the current drawing macro completed. Functions placed in the foreground ran before either, and was often used for timers and other "low latency" needs. Zgrass included a <code>TIMEOUT</code> function that would call macros on a timed basis, making the implementation of timers very easy.

Zgrass included three priorities (called ''levels'') andthat allowed macros to be run normally, or in ''"foreground''" or ''"background''" levels. This added a simple form of [[computer multitasking|multitasking]] which was tremendously useful in aan animation-oriented language. Game authors could place joystick-reading routines in a macro set to run in the background, and then the joystick would be read automatically whenever the current drawing macro completed. Functions placed in the foreground ran before either, and was often used for timers and other "low latency" needs. Zgrass included a <{{code>|TIMEOUT</code>}} function that would call macros on a timed basis, making the implementation of timers very easy.

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 [[cassette tape]] storage, but oddly the syntax was marred, disk commands were D-something, like <code>DPUT</code> while tape commands were something-TAPE, like <code>PUTTAPE</code>. Its not clear why this difference in syntax existed <code>TPUT</code> seems like a better solution.

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 [[cassetteCompact tapeCassette (data)|Compact Cassette]] storage, but oddly the syntax was marred,not parallel: disk commands were D-something, like <{{code>|DPUT</code>}}, whilebut tape commands were somethingnot T-TAPEsomething, like <{{code>PUTTAPE</code>.|TPUT}}, Itsbut notrather clearsomething-TAPE, whylike this difference in syntax existed <{{code>TPUT</code> seems like a better solution|PUTTAPE}}.

With programs constructed from random 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 I (very common) then they could set each others values leading to hard to debug problems. Zgrass allowed one to use [[lowercase]] letters for variables, in which case the variable was local only to that macro. Oddly their own examples do not make much used of this, although it should have been suggested as the standard method for naming variables.

With programs constructed from arbitrarily 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 ===

=== Example ===

<code>

{{sxhl|2=basic|1=<nowiki/>

SINCURVE=[PROMPT "WHAT IS THE OFFSET?"<br>

INPUT OFFSET<br>

x=-160<br>

angle=0<br>

angle=0
POINT OFFSET+x,SIN(angle)*80,3<br>

angle=angle+2<br>

IF (x=x+1)<159,SKIP -2]<br>

}}

</code>

This example shows several of the novel features of Zgrass. This text creates a new macro called "<code>SINCURVE"</code> that can be called simply by typing it<code>SINCURVE</code> into the command prompt, or from other macros or programs. SINCURVE uses two local variables, <var>x</var> and <var>angle</var>, as well as a global variable, <var>OFFSET</var>.

The <code>PROMPT</code>/<code>INPUT</code> is a modification of the original BASIC version,<code>INPUT</code> which will not ask for the input if the user types it into the command line when calling the macro. In this case, typing <code>SINCURVE</code> will result in the prompt appearing and the program waiting for input, whereas typing <code>SINCURVE 30</code> will skip the prompt and OFFSET will automatically be assigned 30. This allows a single macro to be used both interactively and within a program as a function.

This example shows several of the novel features of Zgrass. This text creates a new macro called "SINCURVE" that can be called simply by typing it into the command prompt, or from other macros or programs. SINCURVE uses two local variables, x and angle, as well as a global variable, OFFSET.

<code>POINT</code> is an example of one of the many graphics commands included in the Zgrass language. <code>POINT</code> requires an X and Y ___location, as well as a color. In this example, the user supplied <code>OFFSET</code> moves the x position of the curve on the screen, while the Y position is supplied by the [[trigonometry|trig function]], suitably enlarged for display (in this case, 80 times). The color is supplied in the last input, and in this case is 3. The Z BoxUV-1 used color registers, so 3 did not imply a particular color, but a color selected from the current palette.

The <code>PROMPT</code>/<code>INPUT</code> is a modification of the original BASIC version, which will not ask for the input if the user types it into the command line when calling the macro. In this case typing <code>SINCURVE</code> will result in the prompt appearing and the program waiting for input, whereas typing <code>SINCURVE 30</code> will skip the prompt and OFFSET will automatically be assigned 30. This allows a single macro to be used both interactively and within a program as a function.

The <code>IF</code> is likewise interestingnotable. It places an increment, <code>(x=x+1)</code>, in front of the test, a feature not normally available in BASIC. In this case the IF is told to call <code>SKIP -2</code> if true, which will move back two lines and can be used in place of a <code>GOTO</code>, as there is no line number target.

<code>POINT</code> is an example of one of the many graphics commands included in the Zgrass language. <code>POINT</code>requires an X and Y ___location, as well as a color. In this example the user supplied <code>OFFSET</code> moves the x position of the curve on the screen, while the Y position is supplied by the trig function, suitably enlarged for display (in this case, 80 times). The color is supplied in the last input, and in this case is 3. The Z Box used color registers, so 3 did not imply a particular color, but a color selected from the current palette.

==Notes==

The <code>IF</code> is likewise interesting. It places an increment, <code>(x=x+1)</code>, in front of the test, a feature not normally available in BASIC. In this case the IF is told to call <code>SKIP -2</code> if true, which will move back two lines and can be used in place of a <code>GOTO</code>.

{{reflist|group=notes}}

==References==

''External links:''

===Citations===

:[http://www.classicgaming.com/ballyalley/misc_docs/misc_docs.html Bally Alley Miscellaneous Documentation]<br>

{{reflist}}

:- includes PDF versions of scans of the UV-1 Zgrass manual

===Bibliography===

{{refbegin}}

* {{cite book |first1=Thomas |last1=DeFanti |first2=Jay |last2=Fenton |first3=Nola |last3=Donato |title=Proceedings of the 5th annual conference on Computer graphics and interactive techniques |chapter=BASIC Zgrass—a sophisticated graphics language for the Bally Home Library Computer |chapter-url=http://dl.acm.org/citation.cfm?id=807366 |publisher=ACM SIGGRAPH Computer Graphics |volume=12 |issue=3 |date=August 1978 |pages=33–37 |doi=10.1145/800248.807366 |isbn=9781450379083 |s2cid=8014940 }}

* {{cite magazine |first=Thomas |last=DeFanti |url=https://archive.org/details/byte-magazine-1980-11-rescan/page/n91/mode/2up |title=Language Control Structures for Easy Electronic Visualization |magazine=BYTE |date=November 1980 }}

{{refend}}

{{BASIC}}

[[Category:Procedural programming languages]]

[[Category:Programming languages created in 1974]]

[[Category:Star Wars (film)]]

[[Category:BASIC programming language family]]