FAQ for Urbane 1.060202 RC0

>> I'm not quite following what your preprocessor does.

It translates the preprocessor language into what DECB requires.

The language IS the DECB language and must follow what is in the various
manuals for the CoCo Basic.

The following changes have been made:

1) Line numbers are not used.

One of the main points of the language is to eliminate line numbers

Line Labels are only required on lines that transfer of control is to.

2) Variables can be of any length and are unique no matter how long
they are.

DECB only considers variables unique when the first two characters are
unique.

That's the second point. That's all of the major differences.

>> Is it a language that compiles into BASIC code?

YES! DECB Code that is run able on a CoCo 2 or CoCo 3. CoCo 2 limited to
what features are in DECB for the CoCo 2.

>> Is the preprocessor itself written in BASIC or is it machine language,
>> etc.?

The preprocessor is written in the preprocessor language. The Flex "XPC" was
the basis of the preprocessor language and I used it to start to develop the
program. Now the Urbane language is very different from the Flex "XPC" Language.

I believe that a version running on GWBASIC (or whatever), the line number
basic for MSDOS, can be generated as well as versions for other line
number basics on any platform.

>> Thanks for creating new CoCo material... this is rare!

This may allow persons who are writing programs in DECB to write them faster
and more complex. Modules can be written in such a way that you just insert
them into your program and call them. We could built up a set of them to
share.

>> Are you going to announce this tool on the CoCo mailing list?

Yes, just as soon as you tell me the links to the files.

> Could you please describe the exact steps we need to follow in order
> to use your Disk BASIC preprocessor, and kindly explain what the
> system can be used for, etc.? A tutorial would be great.

Urbane is designed to allow any DECB program to be written without line numbers and with unique variables of any length. All DECB commands and functions are supported and version 1.060202 is considered complete and ready for use in writing any DECB program.

If you have the distribution package "urbane1_060202.zip"

Then just mount the dsk image ("URBANE.DSK") in your emulator or
write it to a disk file for use with a real CoCo.

"URBANE.BAS". Is the run able DECB version.

Delete all the files in a copy of this "DSK" file except "URBANE.BAS"

Then add your own Source code.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Your program needs to have the name "UBN_IN.TXT" which you create with a
screen editor.

Then a 'RUN"URBANE"' will start the program reading "UBN_IN.TXT" and writing
the DECB version of your program to "UBN_OUT.TXT".

Then you can 'LOAD "UBN_OUT.TXT"' and then type 'RUN' to test your program.

The definition of the language is the "Language.htm" Web page.

This is incomplete and being worked on.

Only what is used by the "UBN_IN.TXT", the preprocessor source code
has been tested.

Feel free to try any of the DECB commands and
functions, version 1.060202 is believed to be complete and is ready for user programs.

Please report any problems (And Success) I may not be testing your favorites
so if you want them to work, try them and report back.

--------------------------------------
These two changes transform DECB into a language that is much more friendly,
easier to write and understand.

A full screen editor is required for writing programs as there are no line
Numbers.

Errors are detected by DECB so it will be a bother to go back to the screen
editor, correct the error(s), run the program through the preprocessor and
then load it into DECB which may complain about another error. Not Good!

This cycle is similar to other development methods. I expect most
program editing will be done on platforms other than the CoCo and
only the run version will be loaded and run on a CoCo.

I have thought about a combination syntax checker program that also will
translate existing DECB programs into the preprocessor language. Removing
unneeded line numbers, converting the remaining ones into strings that are
no longer numbers. Unique variables identified and their use made consistent
and some other things that the preprocessor language requires.

This would allow most syntax errors to be detected on the editing platform.

To simplify the effort I am imposing constraints on the usage of the
Language.

The LET keyword is NOT required. I originally
planned on a syntax driven parser and felt that it might be a difficult task
to not require it.

When I switched to a very much simpler parser, it just was not
required. Strings after the possible Line Label are first checked to see if
the string is a keyword. If not then the Line Label table is checked to see
if it is one. If it is not, then it must be a Variable which is just what we
want to happen when the "LET" keyword is omitted. This much simpler parser
is slower, but easier to code. The goals currently do not include fast
processing, just get a working version that allows all DECB capabilities to
be used. My current estimate of lifetime users is 5 with my self the only
one confirmed. So I am trying to match the current goals with the number of
users but still to do a good and complete job. As the number of users
increases, the goals will be adjusted. The current interest is still in
single digits.

Keywords must be followed by a space. This in addition to making the parser
simpler makes the source code more readable which is a goal.

A space following the "USR" function is required which looks strange.

Example: A_VARIABLE = USR 0(ANOTHER_VARIABLE)

I am assuming a syntactically correct program is being processed and that
DECB will report any errors. If the input is really messed up, then the real
problem may sometimes be hard to find with the most useful information in
the xref file.

Cross Reference information will be written to the "ubn_xrf.txt" file which will
require a post processor to sort and print.

Control characters are not allowed.

What DECB might do with control characters is unknown.

If an editor is used that embeds control characters,
Urbane can change them to spaces if it becomes a problem.

Tab's during pass two are changed to a space and are handled
by the excess space remover. Pass one where the listing is written
will just pass them through unchanged which may or may not
produce a glitch in the listing.

DECB requires the "REM" keyword on a line with just a line number (Line Label).

I plan to go back and check if "'" can be used instead as well as "?"
can be substituted for "PRINT". At the same time I will be looking to
see if the trailing space after a keyword can be removed And if there
would be a benefit to merging lines with no labels. All of this might
speed up the produced RUN version but make the preprocessor slower.

Stephen H. Fischer