223cc6685e
git-svn-id: svn://svn.compuextreme.de/Viitor/V963/Viitor_cc65@5933 504e572c-2e33-0410-9681-be2bf7408885
155 lines
6.8 KiB
HTML
155 lines
6.8 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.20">
|
|
<TITLE>grc -- GEOS Resource Compiler: Resource file format</TITLE>
|
|
<LINK HREF="grc-4.html" REL=next>
|
|
<LINK HREF="grc-2.html" REL=previous>
|
|
<LINK HREF="grc.html#toc3" REL=contents>
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="grc-4.html">Next</A>
|
|
<A HREF="grc-2.html">Previous</A>
|
|
<A HREF="grc.html#toc3">Contents</A>
|
|
<HR>
|
|
<H2><A NAME="s3">3.</A> <A HREF="grc.html#toc3">Resource file format</A></H2>
|
|
|
|
<P>A resource file has the name extension <CODE>.grc</CODE>. That is not required, but
|
|
it will make for an easier recognition of the file's purpose. Also, <B>cl65</B>
|
|
recognizes those files. <B>grc</B>'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 '<CODE>;</CODE>',
|
|
until the end of the line, is considered as a comment, and ignored. See the
|
|
included
|
|
<A HREF="grc-8.html#example-grc">commented example .grc file</A> for a
|
|
better view of the problem.</P>
|
|
|
|
|
|
<H2><A NAME="ss3.1">3.1</A> <A HREF="grc.html#toc3.1">Menu definition</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
MENU menuName leftx,topy <ORIENTATION> {
|
|
"item name 1" <MENU_TYPE> pointer
|
|
...
|
|
"item name x" <MENU_TYPE> pointer
|
|
}
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
The definition starts with the keyword <CODE>MENU</CODE>, then goes the menu's name,
|
|
which will be represented in C as <CODE>const void</CODE>. 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 <CODE>HORIZONTAL</CODE> or
|
|
<CODE>VERTICAL</CODE>. Between <CODE>{</CODE> and <CODE>}</CODE>, 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 <CODE>MENU_ACTION</CODE> or
|
|
<CODE>SUB_MENU</CODE>; either of them can be combined with the <CODE>DYN_SUB_MENU</CODE> bit
|
|
(see
|
|
<A HREF="geos.html">the GEOSLib documentation</A> 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:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
"dynamic" SUB_MENU|DYN_SUB_MENU create_dynamic
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
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.</P>
|
|
<P>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.</P>
|
|
|
|
|
|
<H2><A NAME="ss3.2">3.2</A> <A HREF="grc.html#toc3.2">Header definition</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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
|
|
}
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
The header definition describes the GEOS header sector which is unique to
|
|
each file. Currently, there's no way to change the default <B>grc</B> icon
|
|
(an empty frame). It will be possible in the next version. The definition
|
|
starts with the keyword <CODE>HEADER</CODE>, then goes the GEOS file-type. You can use
|
|
only <CODE>APPLICATION</CODE> 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 "<CODE>V</CODE>x.y", where <EM>x</EM> is the major, and <EM>y</EM> 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 <CODE>author</CODE> and its value in quotes name the
|
|
programmer, and can be up to 63 bytes long. <CODE>info</CODE> (in the same format) can
|
|
have up to 95 characters. If the <CODE>date</CODE> 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 <CODE>dostype</CODE> can be <CODE>SEQ</CODE>,
|
|
<CODE>PRG</CODE>, or <CODE>USR</CODE>. <CODE>USR</CODE> is used by default; GEOS usually doesn't care.
|
|
The <CODE>mode</CODE> can be <CODE>any</CODE>, <CODE>40only</CODE>, <CODE>80only</CODE>, or <CODE>c64only</CODE>; and,
|
|
it describes system requirements. <CODE>any</CODE> will work on both 64-GEOS and
|
|
128-GEOS, in 40- and 80-column modes. <CODE>40only</CODE> will work on 128-GEOS in
|
|
40-column mode only. <CODE>80only</CODE> will work on only 128-GEOS in 80-column mode,
|
|
and <CODE>c64only</CODE> will work on only 64-GEOS. The default value for
|
|
<CODE>structure</CODE> is <CODE>SEQ</CODE> (sequential). You can put <CODE>VLIR</CODE> there, too; but
|
|
then, you also have to put in a third type of resource -- a VLIR-table
|
|
description.</P>
|
|
|
|
|
|
<H2><A NAME="ss3.3">3.3</A> <A HREF="grc.html#toc3.3">VLIR table description</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
VLIR headname address {
|
|
vlir0
|
|
blank
|
|
vlir2
|
|
blank
|
|
vlir4
|
|
}
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
The first element is the keyword <CODE>VLIR</CODE>, 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., <CODE>4096</CODE>) or hexadecimal
|
|
with a <CODE>0x</CODE> prefix (e.g., <CODE>0x1000</CODE>). Then, between braces are the names
|
|
of VLIR chain binaries or the keyword <CODE>blank</CODE> 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 <B>ld65</B> 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
|
|
<CODE>.cvt</CODE> file, by <B>grc</B> in its VLIR linker mode.</P>
|
|
<P>The <CODE>headname</CODE> will be the name for the binary file which will contain only
|
|
a GEOS <CODE>.cvt</CODE> header made out of compiling the <CODE>.s</CODE> header file that also
|
|
was generated by <B>grc</B>. At the end of the resulting <B>ld65</B> config. file
|
|
(<CODE>.cfg</CODE>), in comments, there will be information about what commands are
|
|
required for putting the stuff together. Read
|
|
<A HREF="grc-5.html#building-vlir">this description</A> for details.</P>
|
|
|
|
|
|
|
|
<HR>
|
|
<A HREF="grc-4.html">Next</A>
|
|
<A HREF="grc-2.html">Previous</A>
|
|
<A HREF="grc.html#toc3">Contents</A>
|
|
</BODY>
|
|
</HTML>
|