Version 1.30 Notes:

1) Fix optional "THEN" feature

2) Fix #FCN etc. for ANSI (-A) option

3) Add "PROGRAM" statement. This is used to tell the compiler where the
   code section of the program is to begin. It its almost never required
   because the compiler "knows" when the code is to begin EXCEPT if the
   first line of code is C or assembler. If the first line of code is C
   or assembler, use the PROGRAM staement immediately preceeding the first
   line of code.

4) Hexadecimal constants may now be expressed in Motorola, Intel, or C
   style. The formats (using ffff as an example) are:
   Motorola:   $ffff
   Intel:      0ffffh
   C:          0xffff

   In the Intel case, the first character MUST be a digit.

5) Add "HEXOUT" statement. This statement allows control over the output
   of the HEX$() function. In the examples only the first letter is checked
   by the compiler. The default is Motorola ($ffff).

   HEXOUT motorola  (preceeds hex value with "$")
   HEXOUT intel     (preceeds hex value with "0" and adds "h" at end)
   HEXOUT c         (preceeds haex value with "0x")
   Hexout none      (adds nothing)

6) Add ANSI stream file I/O. This causes the C functions fopen(), fread(), etc.
   to be used instead of open(), read(), etc. This was implemented to speed up
   file I/O on certain systems. For most it is of no concern. Stream I/O is
   supported in the following statements and functions:

   1) create
   2) open
   3) close
   4) get
   5) put
   6) read
   7) write
   8) seek
   9) eof()
   10) filsiz()
   11) filpos()

   Stream I/O is NOT supported for the following:
   1) print
   2) input
   3) fprint
   4) finput

   For purposes of explanation, we will refer to the "old" way of doing files
   as "path" and the ANSI way as "stream". The two styles CANNOT be mixed.
   These examples illustrate the usage:

             PATH                            STREAM

   DIM FileNum:BYTE               DIM FilePtr:FILE
   DIM X:LONG                     DIM X:LONG
   X=1234                         X=1234
   CREATE #FileNum,"test":WRITE   CREATE FilePtr,"test":WRITE
   WRITE #FileNum,X               WRITE FilePtr,X
   CLOSE #FileNum                 CLOSE FilePtr
   OPEN #FileNum,"test":UPDATE    OPEN FilePtr,"test":UPDATE
   READ #FileNum,X                READ FilePtr,X
   SEEK #FileNum,0                SEEK FilePtr,0
   PRINT FILPOS(#FileNum)         PRINT FILEPOS(FileNum)
   CLOSE #FileNum                 CLOSE FilePtr

   As you can see, the main difference in the usage is the "#" prefix to the
   path number variable. Not apparent from this example is the fact that you
   cannot assign a value to a FILE variable in an assignment statement. For
   example:

   FilePtr=3

   will cause an error to be reported. While these two methods are radically
   different internally, OmniBasic has made the use of either to appear very
   similar.

   Also note that with stream I/O, CREATEing a file that already exists will
   not cause an error as in path I/O, but rather will delete the old file and
   start a new one with the same name.

7) The "+" character in column 1 now "tells" the compiler that this is an
   assembler statement. In the gcc case (Linux, MSDOS, OS/2, etc.) this is
   quite useful because it eliminates a lot typing for those who like to
   intermix assembler. Using the "nop" instruction as an example, the code
   produced for the C compiler is:

   gcc case:

   +nop        produces __asm__ __volatile__("nop");

   OS-9/OS-9000 case:

   +nop        produces @nop

   In either case no syntax checking is performed. When using inline assembler
   in OmniBasic, it is best to delare any variables using the DIM statement
   rather than by explicit assembler directive. This way, OmniBasic is "aware"
   of the data and the data will automatically appear in the correct segment
   of the resultant .c file.

Version 1.31 Notes:

1) SUBSTR() has been rewritten. An optional third argument specifies the
   postion in arg 2 to start the search. If the third arg is missing, the
   position is 1 by default.

2) Two new functions, UCASE$(StrVar) and LCASE$(StrVar) have been added.
   UCASE$() returns a string converted to uppercase. Correspondingly LCASE$()
   returns a string converted to lower case. The current implementation sets
   a limit of 300 bytes string size for the conversion.

3) Two new statements have been added. MAKEUPPER and MAKELOWER correspond to
   the two new functions (UCASE$(), LCASE$()). The sytax is:

   MAKEUPPER StrVar

   There is no limit on the string size here. The string is converted in place
   which makes thes statements faster than the corresponding functions.

Version 1.32 notes:

1) TAIL$() has been added. The syntax is:

   TAIL$(StrVar,Position)

   TAIL$() returns the string StrVar starting at Position through the end of the
   string.

2) The FILL statement has been added. The syntax is:

   FILL Addr,Quan[,Pattern]

   FILL places the pattern 'Pattern' in memory starting at Addr for Quan
   byte locations. If the 'Pattern' argument is missing, 0's are the pattern.
   Use this statement with caution as FILLing carelessly can result in
   destruction of data and/or system crashes.

3) The INIT statement is similar to the FILL statement except that the
   parameters are obtained from the Var parameters rather than explicit
   arguments. INIT is much safer to use than FILL for this reason. The syntax
   is:

   INIT VAR[,Pattern]

   If Var is a Buffer thaat has been opened, the pattern will be written into
   the buffer from BUFADR(BufName) for BUFSIZ(BufName) byte locations. If the
   buffer BufName has been close (BUFFER BufName=0), INIT BufName will cause
   unpredictable (probably disasterous) results.

4) FINDADDR() and FINDOFFS() have been added. The syntax is:

   FINDADDR(Addr,Quan,Pattern)
   FINDOFFS(Addr,Quan,Pattern)

   Both functions work the same except that FINDADDR returns the address
   of the first byte location which matches 'Pattern' while FINDOFFS
   returns the offset from 'Addr'. Both functions search for a byte match
   of 'Pattern' starting at 'Addr' for 'Quan' bytes.

5) A bug in PEEK() has been fixed.

Version 1.36 Notes:

This version eliminates all of the restrictions on the placement of labels,
statements, functions, and directives into certain column postions. In other
words, for exeample, labels no longer have to start in column 1 and
statements no longer have to be indented at all. Also, directives may
begin in any position. Labels, subroutines, and functions may have a ":"
appended for clarity, but this is optional. See "fcndemo.b" for an
example of the declaring, calling, and defining og functions.

Previous to this release, function definitions were required to begin
in column 1 with "()" appended. Now they may begin in any postion but the "()"
MUST be removed.

This version also allows the substitution of "$" for "#" in directives making
them resemble metastatements from other Basics. For example $INCLUDE is the
same as #INCLUDE.

In DIM statements you may specify "INT" for a 16 bit integer. Keep in mind
"INTEGER" specifies a 32 bit integer. This was added for QB/PB compatibility.

The following shows three distinct styles of programming with OmniBasic. You
can mix and match as you desire, but it is recommended that you develop a
particular style and stick with it for consistancy and readability.

DIM X AS LONG

X=2
GOSUB Test1
PRINT X

Test1:
X=X+1
RETURN


DIM X AS LONG

X=2
GOSUB Test1
PRINT X

Test1
X=X+1
RETURN


 DIM X AS LONG

 X=2
 GOSUB Test1
 PRINT X

Test1
 X=X+1
 RETURN

Version 1.40 Notes:

This version fixes several bugs including READ/WRITE/GET/PUT of portions of
user-defined variables and calculations of SEEK position in stream I/O.

News features include the ability to "know" the program's file name:

PRINT ProgramName

or 

A$=ProgramName
IF A$="test" THEN...

The SETBUFADR statement has been added. This allows just one BUFFER structure
to control any number of buffers by maintaining a table of open buffers and
then closing any buffer by:

BUFFER BufName=2000
x=BUFADR(BufName)

...

SETBUFADR BufName=x
BUFFER BufName=0

This is for advanced programmers and be advised that an invalid SETBUFADR can
cause a system crash or data loss.