Next Previous Contents

## 3. Resource file format

A resource file has the name extension `.grc`. That is not required, but it will make for an easier recognition of the file's purpose. Also, cl65 recognizes those files. grc's parser is very weak, at the moment; so, read the comments carefully, and write resources exactly as they are written here. Look out for CAPS. and small letters. Everything after a '`;`', until the end of the line, is considered as a comment, and ignored. See the included commented example .grc file for a better view of the problem.

## 3.1 Menu definition

> `

>     MENU menuName leftx,topy <ORIENTATION> {
>         "item name 1" <MENU_TYPE> pointer
>         ...
>         "item name x" <MENU_TYPE> pointer
>     }

> `

The definition starts with the keyword `MENU`, then goes the menu's name, which will be represented in C as `const void`. Then are the co-ordinates of the top left corner of the menu box. The position of the bottom right corner is estimated, based on the length of item names and the menu's orientation. It means that the menu box always will be as large as it should be. Then, there's the orientation keyword; it can be either `HORIZONTAL` or `VERTICAL`. Between `{` and `}`, there's the menu's content. It consists of item definitions. First is an item name -- it has to be in quotes. Next is a menu-type bit. It can be `MENU_ACTION` or `SUB_MENU`; either of them can be combined with the `DYN_SUB_MENU` bit (see the GEOSLib documentation for descriptions of them). You can use C logical operators in expressions, but you have to do it without spaces. So, a dynamically created submenu will be something like:

> `

>     "dynamic" SUB_MENU|DYN_SUB_MENU create_dynamic

> `

The last part of the item definition is a pointer which can be any name that is present in the C source code that includes the generated header. It can point to a function or to another menu definition.

If you are doing sub(sub)menu definitions, remember to place the lowest level definition first, and the top-level menu as the last one. That way, the C compiler won't complain about unknown names.

## 3.2 Header definition

> `

>     HEADER <GEOS_TYPE> "dosname" "classname" "version" {
>         author    "Joe Schmoe"
>         info      "This is my killer-app!"
>         date      yy mm dd hh ss
>         dostype   SEQ
>         mode      any
>         structure SEQ
>     }

> `

The header definition describes the GEOS header sector which is unique to each file. Currently, there's no way to change the default grc icon (an empty frame). It will be possible in the next version. The definition starts with the keyword `HEADER`, then goes the GEOS file-type. You can use only `APPLICATION` here at the moment. Then, there are (each one in quotes) the DOS file-name (up to 16 characters), the GEOS Class name (up to 12 characters), and the version info (up to 4 characters). The version should be written as "`V`x.y", where x is the major, and y is the minor, version number. Those fields, along with both braces, are required. The lines between braces are optional, and will be replaced by default and current values. The keyword `author` and its value in quotes name the programmer, and can be up to 63 bytes long. `info` (in the same format) can have up to 95 characters. If the `date` field is omitted, then the time of that compilation will be placed into the header. Note that, if you do specify the date, you have to write all 5 numbers. The `dostype` can be `SEQ`, `PRG`, or `USR`. `USR` is used by default; GEOS usually doesn't care. The `mode` can be `any`, `40only`, `80only`, or `c64only`; and, it describes system requirements. `any` will work on both 64-GEOS and 128-GEOS, in 40- and 80-column modes. `40only` will work on 128-GEOS in 40-column mode only. `80only` will work on only 128-GEOS in 80-column mode, and `c64only` will work on only 64-GEOS. The default value for `structure` is `SEQ` (sequential). You can put `VLIR` there, too; but then, you also have to put in a third type of resource -- a VLIR-table description.

## 3.3 VLIR table description

> `

>     VLIR headname address {
>         vlir0
>         blank
>         vlir2
>         blank
>         vlir4
>     }

> `

The first element is the keyword `VLIR`, then goes the name for the header binary file (read below), and the base address for all VLIR chains that are different from 0. It can be either decimal (e.g., `4096`) or hexadecimal with a `0x` prefix (e.g., `0x1000`). Then, between braces are the names of VLIR chain binaries or the keyword `blank` which denotes empty chains. In the example, chains #1 and #3 are missing. The names between braces are the names of binaries that contain code for each VLIR part. They matter only for the generated ld65 configuration file, and will be the names of the resulting binary files after linking. Each one will contain one VLIR chain; and, they will have to be put together, in the correct order, into a VLIR `.cvt` file, by grc in its VLIR linker mode.

The `headname` will be the name for the binary file which will contain only a GEOS `.cvt` header made out of compiling the `.s` header file that also was generated by grc. At the end of the resulting ld65 config. file (`.cfg`), in comments, there will be information about what commands are required for putting the stuff together. Read this description for details.

Next Previous Contents